· Gliederung 1. Verteilte, nebenl au ge, interaktive Systeme 1 1.1. Vorbemerkungen zu verteilten...

Grundlagen derProgramm- undSystementwicklung II

Modellierung verteilter Systeme

Manfred Broy

Sommersemester 2014

Institut fur Informatik

Technische Universitat Munchen

Gliederung

1. Verteilte, nebenlaufige, interaktive Systeme 11.1. Vorbemerkungen zu verteilten Systemen . . . . . . . . . . . . . . . . 21.2. Grundbegriffe und Grundkonzepte . . . . . . . . . . . . . . . . . . . . 31.3. Wesentliche Eigenschaften vernetzter Systeme . . . . . . . . . . . . . 51.4. Fundamentale Fragen bei der Modellierung vernetzter Systeme . . . . 71.5. Ein einfuhrendes Beispiel: Das

”Alternating-Bit“-Protokoll . . . . . . 9

1.6. Geschichtliche Bemerkungen zur Entwicklung der methodischen Grund-lagen verteilter Systeme . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.7. Ubungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2. Zustandssicht: Systeme als Zustandsmaschinen 192.1. Zustandsubergangssysteme . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1. Zustandsmaschinen mit unmarkierten Ubergangen . . . . . . . 202.1.2. Zustandsmaschinen mit markierten Ubergangen . . . . . . . . 302.1.3. Zustandsubergangsdiagramme . . . . . . . . . . . . . . . . . . 33

2.2. Logische Modellierung von Zustandsmaschinen . . . . . . . . . . . . . 332.2.1. Zustande als Variablenbelegungen . . . . . . . . . . . . . . . . 332.2.2. Kontrollzustande als Pradikate in Zustandsubergangsdiagramm-

en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.3. Zustandsubergangssysteme als anweisungsorientierte Program-

me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.4. Anweisungsorientierte Programme als Zustandsubergangssys-

teme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3. Zustandsmaschinen mit Eingabe und Ausgabe . . . . . . . . . . . . . 412.4. Darstellungen von Zustandsmaschinen . . . . . . . . . . . . . . . . . 43

2.4.1. Analytische Darstellung . . . . . . . . . . . . . . . . . . . . . 442.4.2. Graphische Darstellung . . . . . . . . . . . . . . . . . . . . . . 452.4.3. Tabellarische Darstellung . . . . . . . . . . . . . . . . . . . . . 452.4.4. Matrix–Darstellung . . . . . . . . . . . . . . . . . . . . . . . . 48

2.5. Klassen und Objekte als Zustandsmaschinen . . . . . . . . . . . . . . 502.6. Nebenlaufigkeit und Parallelitat . . . . . . . . . . . . . . . . . . . . . 542.7. Parallele Programme mit gemeinsamen Variablen . . . . . . . . . . . 58

2.7.1. Gemeinsame Variable . . . . . . . . . . . . . . . . . . . . . . . 592.7.2. Stabile Pradikate und Invarianten bei paralleler Komposition . 63

18. Marz 2014 I

Gliederung

2.7.3. Parallele Programme, unteilbare Aktionen, gegenseitiger Aus-schluß und Koordination . . . . . . . . . . . . . . . . . . . . . 65

2.7.4. Zusicherungsbeweise fur parallele Programme, Geistervariable 702.8. Historische Bemerkungen zur Zustandssicht auf verteilte Systeme . . 752.9. Ubungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3. Schnittstellensicht: Funktionale Beschreibung von System-

komponenten 793.1. Schnittstellenabstraktion . . . . . . . . . . . . . . . . . . . . . . . . . 793.2. Syntaktische Schnittstellen: Kanale und gemeinsame Variablen . . . . 823.3. Strome und stromverarbeitende Funktionen . . . . . . . . . . . . . . 84

3.3.1. Die Rechenstruktur der Strome . . . . . . . . . . . . . . . . . 843.4. Stromverarbeitende Funktionen . . . . . . . . . . . . . . . . . . . . . 863.5. Zusammenhang zur Objektorientierung . . . . . . . . . . . . . . . . . 953.6. Spezifikation von Stromen . . . . . . . . . . . . . . . . . . . . . . . . 973.7. Spezifikation stromverarbeitender Funktionen . . . . . . . . . . . . . 983.8. Systeme mit benannten Kanalen . . . . . . . . . . . . . . . . . . . . . 1023.9. Schnittstellenabstraktion: Von stromverarbeitenden Funktionen zu Zu-

standsmodellen und zuruck . . . . . . . . . . . . . . . . . . . . . . . . 1053.9.1. Zustandsmaschinen zur Beschreibung stromverarbeitender Funk-

tionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.9.2. Stromverarbeitende Funktionen als Zustandsmaschinen . . . . 106

3.10. Schnittstellenbeschreibungen fur Zustandsmaschinen . . . . . . . . . . 1073.11. Historische Bemerkung zu Schnittstellensichten . . . . . . . . . . . . 1083.12. Ubungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4. Komposition, Struktur- und Verteilungssicht 1114.1. Architekturen und verteilte Systeme . . . . . . . . . . . . . . . . . . . 111

4.1.1. Architekturen und zusammengesetzte Systeme . . . . . . . . . 1124.1.2. Parallele Komposition . . . . . . . . . . . . . . . . . . . . . . 1134.1.3. Modularitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.2. Datenflussnetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144.2.1. Systeme als Datenflussnetze . . . . . . . . . . . . . . . . . . . 1144.2.2. Komponenten von Datenflussnetzen . . . . . . . . . . . . . . . 1164.2.3. Parallele Komposition . . . . . . . . . . . . . . . . . . . . . . 1174.2.4. Nichtdeterministische Komponenten . . . . . . . . . . . . . . . 118

4.3. Kommunikationsnetze . . . . . . . . . . . . . . . . . . . . . . . . . . 1184.3.1. Algorithmen als Datenflussnetze . . . . . . . . . . . . . . . . . 1194.3.2. Kantenfuhrung in Kommunikationsnetzen . . . . . . . . . . . 1224.3.3. Systeme als Kommunikationsnetze . . . . . . . . . . . . . . . 1234.3.4. Berechnung von Funktionen durch Datenflussnetze . . . . . . 125

II 18. Marz 2014

Gliederung

4.4. Kompositionsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274.4.1. Parallele Komposition ohne Ruckkopplung . . . . . . . . . . . 1284.4.2. Ruckkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294.4.3. Sequentielle Komposition . . . . . . . . . . . . . . . . . . . . . 129

4.5. Pradikative Spezifikation von Kommunikationsanweisungen . . . . . . 1354.6. Parallele Komposition zuweisungsorientierter interaktiven Programme 141

4.6.1. Parallele Komposition von Programmen die uber Kanale kom-munizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

4.6.2. Interaktive Systeme zuweisungsorientierter Programme . . . . 1454.7. Parallele Komposition von Programmen mit gemeinsamen Variablen . 146

4.7.1. Komposition von Aktionen auf Zustanden . . . . . . . . . . . 1474.8. Historische Bemerkungen zur Struktur- und Verteilungssicht . . . . . 150

5. Ablaufsicht: Prozesse als Ablaufe verteilter Systeme 1535.1. Nebenlaufige Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . 153

5.1.1. Aktionsstrukturen . . . . . . . . . . . . . . . . . . . . . . . . 1545.1.2. Eigenschaften von Prozessen . . . . . . . . . . . . . . . . . . . 1565.1.3. Sequentielle Prozesse als Strome von Aktionen . . . . . . . . . 160

5.2. Ablaufe als Zustandsfolgen und temporale Logik . . . . . . . . . . . . 1615.3. Koordination, gegenseitiger Ausschluss . . . . . . . . . . . . . . . . . 1645.4. Zusammenhang zwischen Schnittstellenverhalten und Ablaufen . . . . 1685.5. Ablaufe verteilter kommunizierender Systeme . . . . . . . . . . . . . 1695.6. Historische Bemerkungen zur Ablaufsicht . . . . . . . . . . . . . . . . 171

6. Nachrichtensynchrone Systeme 1736.1. Nachrichtensynchrone Komposition von Automaten . . . . . . . . . . 1736.2. Syntax von CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756.3. Operationelle Semantik fur CSP . . . . . . . . . . . . . . . . . . . . . 1786.4. Bereitschaft und Verweigerung . . . . . . . . . . . . . . . . . . . . . . 1816.5. Historische Bemerkungen zur Modellierung nachrichtensynchroner Sys-

teme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.6. Ubungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7. Von der Zustands- zur Ablaufsicht 1877.1. Aktionsstrukturen und Zustandsbegriffe . . . . . . . . . . . . . . . . 1877.2. Temporale Logik zustandsorientierter Systeme . . . . . . . . . . . . . 1887.3. Aquivalenzbegriffe fur Zustandsmaschinen mit markierten Ubergangen1907.4. Der Zusammenhang zwischen Bisimulation und Verweigerungsaqui-

valenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1927.5. Historische Bemerkungen zum Zusammenhang zwischen Zustands-

und Ablaufsicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

18. Marz 2014 III

Gliederung

8. Verfeinerung von Systemen 1998.1. Eigenschaftsverfeinerung . . . . . . . . . . . . . . . . . . . . . . . . . 1998.2. Teilfunktionalitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2018.3. Reprasentations- und Abstraktionsverfeinerung . . . . . . . . . . . . 2028.4. Modularitat und Kompatibilitat . . . . . . . . . . . . . . . . . . . . . 2068.5. Reprasentationsverfeinerung fur Zustandssysteme . . . . . . . . . . . 2078.6. Konstruktion abstrakter Zustandsmaschinen . . . . . . . . . . . . . . 2128.7. Historische Bemerkung zur Verfeinerung von Systemen . . . . . . . . 214

9. Zeitmodellierung 2159.1. Ein einfaches diskretes Zeitmodell . . . . . . . . . . . . . . . . . . . . 2169.2. Zeitsynchrone Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 217

9.2.1. Zeitsynchrone, nachrichtenasynchrone Systeme . . . . . . . . . 2189.2.2. Zeitsynchrone, nachrichtensynchrone Systeme . . . . . . . . . 219

9.3. Perfekte Synchronie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.4. Historische Bemerkung zur Zeitmodellierung . . . . . . . . . . . . . . 219Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

A.Anhang1 233A.1. Komposition von Assumption/Guarantee-Spezifikationen von Aktionen233

B.Unterschiedliche Sichten: FOCUS und Reo 234B.1. Einfuhrung in FOCUS . . . . . . . . . . . . . . . . . . . . . . . . . . 235

B.1.1. Allgemeine Eigenschaften . . . . . . . . . . . . . . . . . . . . 235B.1.2. Beschreibungstechniken . . . . . . . . . . . . . . . . . . . . . . 236B.1.3. Strome und Operatoren auf Stromen . . . . . . . . . . . . . . 236B.1.4. Verfeinerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

B.2. Einfuhrung in Reo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238B.2.1. Allgemeine Eigenschaften . . . . . . . . . . . . . . . . . . . . 238B.2.2. Strome und Co-Induktion . . . . . . . . . . . . . . . . . . . . 239B.2.3. Konnektoren in Reo . . . . . . . . . . . . . . . . . . . . . . . 240

B.3. ABP-Reprasentation in FOCUS . . . . . . . . . . . . . . . . . . . . . 242B.4. ABP-Reprasentation in Reo . . . . . . . . . . . . . . . . . . . . . . . 244

B.4.1. Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245B.4.2. Medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249B.4.3. Empfanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250B.4.4. Komposition von Konnektoren . . . . . . . . . . . . . . . . . . 252

IV 18. Marz 2014

1. Verteilte, nebenlaufige, interaktiveSysteme

Wir beschaftigen uns im folgenden mit verteilten, interaktiven, vernetzten, infor-mationsverarbeitenden Systemen, insbesondere mit ihren Verhalten, ihren zeitlichenund raumlichen Verteilungsaspekten sowie Fragen der Nebenlaufigkeit, der Kommu-nikation und Kooperation. Dabei schließen wir in unsere Betrachtungsweise sowohlreale, physikalische oder technische Systeme (

”Hardware“, mechatronische) Systeme,

betriebswirtschaftliche Systeme, Systeme aus Hardware und informationsverarbei-tender Software wie auch reine Softwaresysteme (

”virtuelle Systeme“) ein. Kom-

plexe reale technische oder organisatorische Systeme, die wir betrachten, bestehenaus Hardware, Software, menschlichen Bearbeitern und/oder mechanischen Gerateneinschließlich Bedienschnittstellen, Sensoren und Aktuatoren. Die Betonung liegt imFolgenden allerdings auf Softwaresystemen und auch auf allen Aspekten ihres Ver-haltens, ihrer Struktur, ihrer Modellierung und Programmierung. Softwaresystemekonnen dabei letztlich auch als Modelle physikalischer, technischer oder betriebs-wirtschaftlicher Systeme verstanden werden.

Typische Anwendungen verteilter, interaktiver Systeme finden sich in Rechnernet-zen, verteilten Rechensystemen, in der Telekommunikation und in der Form einge-betteter Systeme in Automaten der Automatisierungstechnik, Robotik, Fahrzeugen,Flugzeugen, in Haushaltsgeraten und der Weltraumfahrt. In der Systemprogram-mierung, der Gestaltung von Kommunikationsnetzen und Betriebssystemen werdenebenfalls haufig Aufgaben bearbeitet, die Reaktivitat, die Koordination nebenlaufi-ger Aktivitaten und eine zumindest konzeptuelle, oft auch raumliche Verteilungerfordern.

Ein weiteres klassisches Gebiet verteilter Systeme sind verteilte betriebswirtschaft-liche Anwendungen der Informatik. Die Organisation, die Struktur und den Aufbau,aber auch die Prozesse in betriebswirtschaftlichen Anwendungen konnen wir gleich-falls als verteilte, nebenlaufige, interagierende Systeme auffassen und modellieren.Dies gilt gleichermaßen fur die Software in diesem Anwendungsgebiet.

Wir beschranken uns im Weiteren bewusst auf diskrete Systeme, wie sie fur die diskretesSystemInformatik typisch sind. Dies sind Systeme, in denen sich uber die Zeit kontinuierlich

verandernde Werte, wie in der Differential- und Integralrechnung, nicht auftreten,sondern Anderungen immer in diskrete Ubergangen (

”sprunghaft“) erfolgen. Bei

Systemen, in denen kontinuierliche Anderungen betrachtet werden, sprechen wir vonanalogen Systemen. Diese Systeme werden beispielsweise in der Physik, im Maschi- analoges

Systemnenbau, in der Regelungstechnik oder der analogen Elektrotechnik betrachtet. Sie

18. Marz 2014 1

Kapitel 1. Verteilte, nebenlaufige, interaktive Systeme

werden durch stetige Funktionen uber den reellen Zahlen modelliert, insbesonderedurch Differentialgleichungen.

In einer Reihe von Anwendungsgebieten konnen auch Mischformen auftreten, indenen analoge und diskrete Anteile in Systemen vertreten sind. Wir sprechen dannvon hybriden Systemen. Hybride Systeme stehen fur eingebettete Systeme, wie siehybrides

System beispielsweise in Fahrzeugen im Einsatz sind. Das Thema hybride Systeme erfordertumfangreiche Kenntnisse der Kontroll- und Rechnungstechnik sowie der Differential-wie auch Integralrechnung. Hybride Systeme stehen nicht im Mittelpunkt des fol-genden Textes. Wir werden uns ausschließlich auf digitale, diskrete Systeme konzen-trieren.

1.1. Vorbemerkungen zu verteilten Systemen

Ursprunglich waren Rechenanlagen rein sequentiell und wurden zur Ausfuhrung se-quentieller Algorithmen fur Berechnungen, spater auch zur Speicherung umfangrei-cher Datenmengen eingesetzt. Fur diese Art der Nutzung und des Betriebes von Re-chenanlagen waren Nebenlaufigkeit und Verteilung zunachst kein Thema. Mit demMehrbenutzerbetrieb und der Multiplexverwendung von Rechenanlagen, den daraufberuhenden Fragen in Hinblick auf die Gestaltung von Betriebssystemen, mit demAnschluss weiterer elektronischer Gerate, insbesondere elektronischer Peripherie, mitder Vernetzung der Rechner untereinander und mit dem Einsatz der Rechner zurSteuerung technischer und physikalischer Prozesse (eingebettete Systeme) kam demThema der Verteilung von Systemen sowie der damit verbundenen Interaktion undder Nebenlaufigkeit, aber auch der Echtzeitfahigkeit schnell eine sehr viel großereBedeutung zu. Heute weisen alle großeren Softwaresysteme Elemente von Verteilungund Nebenlaufigkeit auf.

Trotzdem andern sich die Programmier- und Modellierungsparadigmen, die starkvon Sequentialitat gepragt sind, erst allmahlich. So ist aufschlussreich festzuhalten,dass die erste objektorientierte Sprache, namlich Simula 67, durch die die Objek-torientierung als solches uberhaupt erst durch die Arbeiten von Johan Ole Dahlund Kristen Olsen Nygaard begrundet wurde, bereits explizit auf Nebenlaufigkeitdurch das Coroutinenkonzept ausgerichtet war (vgl. [DN65]). Trotzdem finden sichin spateren objektorientierten Sprachen fast uberhaupt keine oder nur sehr ad-hoc-artig hinzugefugte Konzepte der Nebenlaufigkeit.

Unbeschadet davon gewinnt das Thema der Nebenlaufigkeit, der Vernetzung, derInteraktion und der Koordination von vernetzten Systemen von Programmen eineimmer starkere Bedeutung in nahezu allen Anwendungen der Informatik. Dies ist dieFolge typischer Anforderungen an heutige Systemen im Zeichen des Internets undanderer Kommunikationsnetze. Fast alle Softwaresysteme laufen heute in irgendeinerForm vernetzt ab, fast alle Rechner sind in irgendeiner Form vernetzt.

Zunehmend haufiger finden sich Systeme, die nicht nur untereinander vernetzt,sondern auch mit physikalischen und technischen Prozessen uber Sensoren und Ak-

2 18. Marz 2014

1.2. Grundbegriffe und Grundkonzepte

tuatoren verbunden sind und zudem interaktive Benutzerschnittstellen aufweisen.Wir sprechen von eingebetteten Systemen. Die Modellierung solcher Systeme bringtvollig neue Fragestellungen und Probleme im Vergleich zu sequentiellen Program-men. Der folgende Text widmet sich auch diesen Fragestellungen.

Man muss sich dabei vor Augen fuhren, dass fur die Entwicklung nebenlaufigerSysteme eine ganze Reihe unterschiedlicher Aspekte zu berucksichtigen sind. Zumeinen sind das die typischen Algorithmen und Protokolle, die in diesem Zusammen-hang von Bedeutung sind. Dies wird in der Informatik unter dem Stichwort

”Verteilte

Algorithmen“ abgehandelt. Eine umfassende Einfuhrung in diese Thematik findetsich in dem Buch von Fred Schneider [Sch97]. Ein zweiter Aspekt ist das Themader technischen Architekturen und Infrastrukturen, bestimmt durch heute typischeBetriebssysteme (wie Echtzeitbetriebssysteme) und Kommunikationseinrichtungen(vgl. [Tan03]).

Im Zentrum werden im Weiteren weniger diese technischen Aspekte als vielmehrgrundsatzliche Konzepte und Modelle fur verteilte Systeme behandelt sowie Moglich-keiten, diese zu beschreiben, zu spezifizieren, zu strukturieren, ihre Eigenschaften zuanalysieren und schließlich auch zu verifizieren. Somit widmet sich dieses Buch spe-ziell den Fragen der Beschreibung und Analyse verteilter Systeme, der gangigen Mo-delle und ihrer Theorie, Struktur sowie Zusammenhange. Der Leser sollte sich jedochimmer vor Augen fuhren, dass es zur Gestaltung eines verteilten Systems neben denFahigkeiten, die Zusammenhange eines solchen Modells zu modellieren, daruber hin-aus von hochster Bedeutung ist, geschickte, technisch gunstige Losungen zu finden,die auch in Richtung auf Kosten, Effizienz, Performanz, Zuverlassigkeit und weitereQualitatsmerkmale wie Wartbarkeit, Partierbarkeit oder Wiederverwendbarkeit allespezifischen Anforderungen erfullen.

1.2. Grundbegriffe und Grundkonzepte

Fur viele informationsverarbeitende Systeme – insbesondere, wenn sie interaktiv,vernetzt und eingebettet, in enger Interaktion mit ihren Nutzern oder ihrer techni-schen Umgebung arbeiten – sind folgende Aspekte von zentralem Interesse:

(0) Kapselung und Schnittstellenbildung : Ein System wird durch eine eindeutig KapselungSchnittstellefestgelegte Systemgrenze von seiner Umgebung abgegrenzt. Diese Systemgren-

ze definiert eine Schnittstelle. Dadurch wird festgelegt, was Teil des Systemsist und was Teil seiner Umgebung ist.

(1) Verteilung : Ein verteiltes System besteht aus einer Familie eigenstandiger, Verteilung

von einander klar abgegrenzter Komponenten mit einer raumlichen oder kon-zeptuellen (strukturellen oder logischen) Verteilung. Die Wahl der Verteilungkann nach ganz unterschiedlichen Gesichtspunkten erfolgen, wie etwa nachraumlichen Gesichtspunkten oder etwa aufgabenorientiert nach logischen Ge-

18. Marz 2014 3


sichtspunkten.

(2) Parallelitat (Nebenlaufigkeit): Die Komponenten eines Systems und damit dasParallelitatNebenlaufig-keit

System selbst fuhren gewisse Aktionen zeitlich nebeneinander (gleichzeitig –

”simultan“) durch.

(3) Kommunikation, Reaktion und Interaktion: Das System tauscht mit seinerKommunika-tion ReaktionInteraktion

Umgebung uber seine Schnittstelle oder die Komponenten des Systems tau-schen untereinander oder mit ihrer Systemumgebung Informationen aus. Dieskann durch Nachrichtenaustausch wie das Senden und Empfangen von Nach-richten oder Signalen erfolgen oder durch Zugriff auf gemeinsamen Speicher.

(4) Koordination: Es bestehen gewisse zeitliche oder kausale Abhangigkeiten, Be-Koordination

ziehungen und Einschrankungen zwischen den Aktionen der unterschiedlichenKomponenten, diese ergeben sich aus der Aufgabenstellung und bestimmendie Logik der Ablaufe.

(5) Quantitative Zeit : Oft sind zeitliche Aspekte bedeutsam. Die zeitlichen Bezie-quantitativeZeit hungen zwischen den Aktionen und die Zeitdauer gewisser Aktionen sind fur

die Systemwirkung entscheidend. Wir sprechen von Echtzeitanforderungen.

Die adaquate mathematische Modellierung und die Implementierung diskreter, in-teraktiver, verteilter, kooperierender Systeme beschaftigt die Informatik seit langem.Bei der Beschreibung parallel ablaufender interaktiver, verteilter Systeme und Pro-gramme treten im Vergleich zu sequentiellen, nichtinteraktiven Programmen eineReihe zusatzlicher Phanomene und Schwierigkeiten auf. Besonderes Augenmerk ver-dient dabei die Interaktion zwischen den Systemteilen und zwischen einem Systemund seiner Umgebung.

Ein interaktives System kann nicht einfach als simple Funktion oder Relation dar-gestellt werden, die einen Satz von Argumenten oder einen Zustand in einem Schritt(oder einer Folge von Schritten) auf ein Ergebnis oder einen Zustand abbildet. Wirmussen bei der Modellierung interaktiver Systeme dem Umstand Rechnung tragen,dass wahrend des Ablaufs (zwischen den Ausfuhrungsschritten) immer wieder In-teraktionen beispielsweise in Form von Zwischeneingaben und -ausgaben uber dieSystemschnittstellen anfallen, die das Systemverhalten entscheidend bestimmen. DasSystem interagiert mit seiner Umgebung in einer Folge von Schritten. Bei interakti-ven Systemen, die in technische Umgebungen eingebettet sind und diese uberwachenund steuern, sprechen wir von eingebetteten Systemen oder auch von reaktiven Sys-temen.

Typische Beispiele fur Anwendungsgebiete verteilter, kommunizierender Systemesind im Einzelnen:

� Systeme zur Unterstutzung betrieblicher Ablaufe (Workflow-Systeme, verteilteBuchungssysteme), verteilte Abrechnungssysteme,

4 18. Marz 2014

1.3. Wesentliche Eigenschaften vernetzter Systeme

� Rechnernetze und Anwendungen darauf (Client/Server-Systeme, Internet,World Wide Web, Web Services),

� Systeme zur massiv parallelen Berechnung komplexer Aufgaben (wissenschaft-liches Hochleistungsrechnen, Simulation, Wettervorhersage),

� Telekommunikation (Telefonvermittlungssysteme, Videosignalubertragung, mo-bile Kommunikation),

� eingebettete reaktive technische Systeme (Steuerungs- und Uberwachungssys-teme in Land-, Wasser-, Raum- und Luftfahrzeugen, in der Haushaltstechnikin Gebauden, Verkehrstechnik, Medizintechnik, Unterhaltungselektronik),

� Produktionssteuerungssysteme (Automatisierungstechnik, Robotik),

� autonome Agentensysteme,

� systemnahe Programmierung (Betriebssysteme, Kommunikationsnetze, Midd-leware),

� Modellierung digitaler Hardware (Schaltwerke und Schaltnetze).

Dies zeigt bereits die große Bedeutung, Spannweite und Vielfalt verteilter, interak-tiver Systeme. Obwohl alle diese Anwendungsgebiete unterschiedliche charakteris-tische Fragestellungen aufwerfen und oft spezielle Beschreibungstechniken zur Dar-stellung von Systemen verwenden, gibt es doch viele Gemeinsamkeiten bei den Mo-dellierungsaufgaben und der Analyse von Systemeigenschaften.

1.3. Wesentliche Eigenschaften vernetzter Systeme

Welche Eigenschaften eines vernetzten, verteilten Systems fur uns im Einzelnen vonInteresse sind, hangt wesentlich davon ab, ob wir ein System lediglich nutzen oder esumfassend analysieren oder gar erst nach bestimmten Vorgaben realisieren (

”entwi-

ckeln“) wollen. Abhangig davon und von den speziellen Gegebenheiten und Beson-derheiten eines Systems sind unterschiedliche Modellierungssichten und Fragen furein vernetztes System von Bedeutung. Nachstehend geben wir eine Reihe einfacherBeispiele fur charakteristische Fragestellungen im Zusammenhang mit vernetztenSystemen.

Schnittstellensicht oder Nutzungssicht (auch Dienstsicht oder funktionale Sicht ge-nannt):

� Welche Funktionalitat und welche Dienste stellt das System fur die Nutzerbereit (Nutzungsfalle)?

18. Marz 2014 5


� In welcher Weise ist das Verhalten des Systems mit dem Verhalten seiner Um-gebung gekoppelt (welche Interaktionen und welche Wechselwirkungen tretenan den Systemgrenzen auf)?

� Welche Annahmen werden fur den ordnungsgemaßen Einsatz des Systems uberseine Umgebung getroffen und welche Garantien halt das System unter diesenAnnahmen ein?

Ein wesentlicher Aspekt interaktiver Systeme ist die Zustandssicht, die folgendeFrage aufwirft:

� Welche Zustande treten auf? Welchen Zustandsraum besitzt das System?

� Welche Zustandsubergange treten auf?

� Durch was werden Zustandsubergange ausgelost?

� Welche Effekte haben Zustandsubergange?

Komponenten-, Verteilungs-, und Struktursicht (auch Systemarchitektur):

� Wie ist ein zusammengesetztes System in Teilsysteme (Komponenten) unter-gliedert?

� Mit welchem Komponentenbegriff wird dabei gearbeitet?

� Welche Komponenten und Komponententypen treten auf?

� Wie kooperieren Komponenten?

� Welche Komponenten kooperieren miteinander?

� Wie werden die Komponenten zu großeren Systemen zusammengesetzt (kom-poniert)?

� Welche Rollen nehmen die einzelnen Komponenten ein und welches Verhaltenzeigen sie?

Kommunikationssicht und Interaktionssicht:

� Zwischen welchen Systemteilen (etwa System und Umgebung) werden welcheInformationen zu welchem Zweck ausgetauscht?

� In welcher Weise, nach welchen Regeln und mit welchen Mitteln tauschenSystemteile Informationen aus?

� Welche Informationen werden ausgetauscht?

6 18. Marz 2014

1.4. Fundamentale Fragen bei der Modellierung vernetzter Systeme

Ablaufsicht:

� Welche Aktionen und Ereignisse treten in welche Folge auf?

� In welchen kausalen Abhangigkeiten sind die Aktionen und Ereignisse?

� Welche Aktionen und Ereignisse durfen nicht gleichzeitig ausgefuhrt werden?

� Welche Ablaufe (Aktions- und Ereignisfolgen) treten auf?

� Was sind typische Ablaufmuster?

In vielen Fallen bestehen in Systemen Zeitabhangigkeiten. Wir sprechen von derZeitsicht auf ein System (auch von

”Echtzeitsystemen“):

� Sind die genauen Zeitpunkte, die zeitlichen Abstande oder die Zeitdauer derAktionen im System fur das Systemverhalten wesentlich?

� Welcher Zeitbegriff ist angemessen (wie wird Zeit gemessen)?

� Welcher Zusammenhang besteht zwischen den zeitlichen Beobachtungen undden ubrigen Systemeigenschaften?

� Was sind die Zeitanforderungen an ein System?

� Was sind die Ausfuhrungs- und Reaktionszeiten eines Systems?

Die unterschiedlichen Sichten auf ein System konnen und mussen in einer umfassen-den Systemmodellierung ermittelt und dokumentiert werden und auch zueinanderin Beziehung gesetzt werden.

Schon bei der Formulierung der Fragen wird deutlich, welchen entscheidendenEinfluß die Terminologie hat. Eine prazise Begriffsbildung ist deshalb ein wesentli-ches Ziel unseres Textes. Die Begriffsbildung geht eng mit einer sorgfaltig gewahltenModellbildung einher, die sich ihrerseits auf mathematische Konzepte stutzt.

Wesentliches Hilfsmittel fur die Entwicklung verteilter Systeme sind angemesseneModellierungs- und Beschreibungsmittel. Die komplexen Zusammenhange in Sys-temen mussen exakt, anschaulich und verstandlich dargestellt werden. Je nachdemwelche der Eigenschaften eines Systems modelliert werden sollen, finden sehr unter-schiedliche Beschreibungstechniken dafur Verwendung.

1.4. Fundamentale Fragen bei der Modellierung vernetzter

Systeme

Bei der Modellierung und Entwicklung vernetzter Systeme treten eine Reihe grund-legender Fragen fur die Informatik auf, die alle eng verzahnt sind, aber eigenstandigeThemengebiete darstellen:

18. Marz 2014 7


� welche Modelle existieren prinzipiell fur verteilte Systeme,

� wie formulieren wir Anforderungen an verteilte Systeme,

� wie spezifizieren wir verteilte Systeme,

� wie strukturieren wir verteilte Systeme,

� wie implementieren wir verteilte Systeme,

� wie verifizieren wir Eigenschaften verteilter Systeme,

� wie analysieren wir verteilte Systeme, welche Qualitatsmerkmale sind von Be-deutung,

� welche Losungsansatze (Algorithmen, Datenstrukturen, Entwurfsmuster, Ar-chitekturen) existieren fur die Entwicklung verteilter Systeme.

Wir konzentrieren uns im Weiteren stark auf den Modellierungsaspekt und auchauf Programmierkonzepte. In den vergangenen Jahrzehnten sind zahllose Modellefur verteilte Systeme ausgearbeitet und vorgeschlagen worden. Sie unterscheidensich oft grundlegend in Hinblick auf die Fragen, mit welchen Mitteln sie Systemedarstellen, wie Systeme in Teilsysteme zerlegt oder zusammengesetzt werden, wiedie Teilsysteme interagieren und welche Aspekte verteilter Systeme dargestellt undwelche nicht (und damit

”wegabstrahiert“ bzw. nicht erfaßt werden).

Deshalb stellt sich grundsatzlich die Frage, was eigentlich ein brauchbares Modellfur ein verteiltes System ist.

Definition: Modell (eines Systems)Modell (einesSystems) Ein Modell ist ein Abbild eines Ausschnittes eines vorgegebenen oder geplanten

realen Systems, erfaßt mit Mitteln der Mathematik, Logik, Informatik, dargestelltdurch Text oder Graphik. Ein Modell bedeutet stets eine Abstraktion. Die Abstrak-tion – Weglassen von Details – dient einem Zweck und erfolgt damit in der Regelunter gewissen Gesichtspunkten. 2

Umso besser das Modell auf den Zweck der Modellbildung zugeschnitten ist, destoeffektiver ist seine Nutzung.

Neben den Modellierungsaspekten gibt es eine Fulle weiterer bedeutsamer Fragenbei der Gestaltung verteilter Systeme, die mit Performanz, Sicherheit, Zuverlassig-keit aber auch mit ganz konkreten Losungen komplexer Aufgabenstellungen durchAlgorithmen, Datenstrukturen und Protokolle zu tun haben. Solche Aspekte ver-netzter Systeme sind von hoher Relevanz, konnen aber nur analysiert und realisiertwerden, wenn geeignete Modelle fur die Systeme verfugbar sind.

Um einen ersten Begriff von der Modellierung von Systemen zu geben wahlen wirein stark vereinfachtes aber plakatives und anschauliches Beispiel, das

”Alternating

8 18. Marz 2014

1.5. Ein einfuhrendes Beispiel: Das”Alternating-Bit“-Protokoll

Bit“ Protokoll. Kernstuck dieses Systems ist die Idee, wie man durch wiederhol-tes Senden des gleichen Wertes unter Verwendung einer Ruckkopplungsschleife, diedaruber informiert, welche Werte ubermittelt wurden, eine korrekte Ubertragungsicherstellt, selbst wenn das Ubertragungsmedium einzelne Nachrichte

”verliert“.

1.5. Ein einfuhrendes Beispiel: Das

”Alternating-Bit“-Protokoll

Verteilte Systeme treten insbesondere in der Telekommunikation auf. Dort werdenbeispielsweise sogenannte Protokolle verwendet, um die Ubertragung von Nachrich-ten zu bewerkstelligen. Ein Protokoll legt bestimmte Regeln und Verfahren fur dieZusammenarbeit zwischen Systemteile fest. Das

”Alternating-Bit“-Protokoll ist ein

vereinfachtes Beispiel fur ein Fehlerkorrekturprotokoll zur Ubertragung von Nach-richten zwischen einem Sender und einem Empfanger, wobei die Ubertragung uberunzuverlassige Medien erfolgt. Systeme mit nicht vollig zuverlassigen Systemteilensind typisch fur eine Reihe von Anwendungen in Rechnernetzen und der Telekom-munikation, aber auch in eingebetteten Systemen. Ein Ziel ist dabei, eine korrekteUbertragung trotz fehlerhafter Teilsysteme zu sichern. Es ist wichtig, dass gera-de Aspekte der zuverlassigen Kommunikation eines verteilten Systems und unzu-verlassiger Teilsysteme angemessen modelliert und analysiert werden konnen.

Wir verwenden das”Alternating-Bit“-Protokoll (ABP) als ein anschauliches und

verhaltnismaßig ubersichtliches Beispiel fur die wichtigen Begriffsbildungen und Kon-zepte. Es handelt sich um ein Protokoll mit Bestatigung ubertragener Nachrichtenund Wiederholung des Sendens bei fehlenden Bestatigungen. Die allgemeine Struk-tursicht auf das System ABP ist im Abb. 1.1 beschrieben. Die Pfeile symbolisierenUbergangskanale, die Blocke Ubergangseinheiten und damit Teilsysteme.

Sender

bs : Bitd : Data Medium2

Medium1Receiver

br : Bit

x : Data

c4 : Bit c3 : Bit

c1 : Data × Bit

r : Data

c2 : Data × Bit

Abb. 1.1.: Struktur- oder Verteilungssicht auf das System ABP

Das ABP dient der Ubertragung eines Nachrichtenstroms uber ein unzuverlassigesMedium. Das Medium ubertragt Nachrichten eines Nachrichtenstroms uber einenKanal. Die Nachrichtenubertragung durch das Medium sei dabei aber unzuverlassig.Es konnen zwischendurch Nachrichten verloren gehen. Die Reihenfolge der Nachrich-ten wird jedoch nicht verandert, ebenso wird jede zu ubertragene Nachricht, wennuberhaupt, unverfalscht und genau einmal ausgeliefert. Mit anderen Worten, das

18. Marz 2014 9


Medium ubertragt die Elemente im Nachrichtenstrom unverandert in der gegebenenReihenfolge, verliert aber unter Umstanden einzelne Nachrichten.

Um den Verlust von Nachrichten feststellen zu konnen (Fehlererkennung) unddie verlorenen Nachrichten erneut senden zu konnen (Fehlerkorrektur), gehen wirim ABP wie folgt vor: Der Sender versieht jede zu sendende Nachricht mit einemzusatzlichen Bit. Die Bits alternieren fur unmittelbar hintereinander zu ubertragen-de Nachrichten. Es entsteht ein Strom von Nachrichten zur Ubertragung, in demnie zwei gleiche Nachrichten aufeinander folgen, da zumindest ihre Bits verschie-den sind. Dadurch konnen Kopien einer wiederholt ubertragenen Nachricht erkanntund unmittelbar aufeinander zu ubertragende, identische Nachrichten vom Fall derWiederholung einer Nachricht unterschieden werden.

Der Sender wiederholt das Senden der aktuell zu ubertragenden Nachricht mitdem aktuellen Bit, bis er das aktuell als Markierung eingesetzte Bit als Bestatigungfur die erfolgreiche Ubertragung zuruck erhalt. Erst dann wechselt er Bit und Nach-richt: Empfangt er ein Bit uber den Bestatigungskanal, so wechselt er zur nachstenNachricht mit dem komplementaren Bit, falls das empfangene Bit dem aktuellenBit entspricht (Bestatigung der Nachricht), andernfalls setzt er die Ubertragung deralten Nachricht und des alten Bits fort.

Wir verwenden hier den Bool-Operator ¬ zur Negation auch fur Bits: Es gelte ¬1= 0 und ¬0 = 1.

Die Komponentensicht auf den Sender ist im Abb. 1.2 gegeben. Abb. 1.3 be-schreibt das Verhalten des Senders durch ein Zustandsubergangsdiagramm.

Sender

bs : Bitd : Data

x : Data

c4 : Bit

c1 : Data × Bit

Abb. 1.2.: Komponentensicht des Senders

Das Medium ist unzuverlassig: Es kann eine Nachricht entweder korrekt ubertragenoder aber verlieren. Das System verwendet zwei Komponenten genannt

”Medium“.

Die Nachrichten, die die Medien ubertragen, sind einmal vom Typ Data × Bit, beste-hen also aus Paaren von Daten und Bit (Richtung

”vom Sender zum Empfanger“),

und zum anderen vom Typ Bit (Richtung”vom Empfanger zum Sender“). Um beide

Medien zusammenfassend behandeln zu konnen, nehmen wir als Typ von Nachrich-ten den generischen Datentyp M. Die Komponentensicht auf das Medium ist imAbb. 1.4 gegeben. Dies ist bereits ein Beispiel fur die Beschreibung einer Klasse vonSystemen. Hier haben wir drei Moglichkeiten:

� Das Medium bekommt eine Nachricht m und leitet sie weiter.

10 18. Marz 2014


Transmission WaitingInput

bs := 1 x : e / {d := e} / c1 : m(d,bs)

{bs:= ¬t} c4 : t / /

{bs = t} c4 : t / {bs := ¬bs}

Abb. 1.3.: Zustandsubergangssicht des Senders. Notation: {Vorbedingung oder Anweisung vorder Ein-/Ausgabe} Input/Output {Nachbedingung oder Anweisung nach der Ein-/Ausgabe}

� Das Medium bekommt eine Nachricht m und leitet diese Nachricht weiternicht.

� Das Medium bekommt keine Nachricht und leitet nichts weiter.

Medium1c1 : M c2 : M

Abb. 1.4.: Komponentensicht des Mediums

Wie bereits betont nehmen wir an, dass das Medium hochstens Nachrichten verliert,aber keine Nachrichten verfalscht, keine neuen Nachrichten generiert und auch Nach-richten nicht in einer anderen Reihenfolge ausliefert als in der sie gesendet wurden.Fur die korrekte Gestaltung und Dokumentation eines Protokolls und die Model-lierung des Systems ist es wichtig, ein genaues Fehlermodell fur das Medium zuentwickeln. Das Verhalten des Mediums ist in der Abb. 1.5 durch ein Zustandsuber-gangsdiagramm beschrieben.Falls das Medium alle Nachrichten verliert, kann mangels uberhaupt ubertragenerInformation eine zuverlassige Ubertragung naturlich nicht gewahrleistet werden. Ga-rantiert das Medium jedoch immer wieder (nach einer endlich Anzahl von Verlusten)eine Ubertragung, so wird letztlich der gesamte Nachrichtenstrom – selbst wenn erunendlich ist – ubertragen. Diese Garantie des Mediums kann durch folgende Bedin-gung einer solchen Fairness der Ubertragung ausgedruckt werden (hier stehen c1 undc2 fur Datenstrome, also fur endliche oder unendliche Sequenzen von Nachrichtenund #c1 fur die Zahl der Nachrichten in dem Strom):

18. Marz 2014 11


Transmission

c1 : m / c2 : mc1 : m /

/

Abb. 1.5.: Zustandsubergangssicht des Mediums

# c1 =∞⇒ # c2 =∞

Der Empfanger (Receiver) erwartet in jedem Zustand der Ubertragung Nachrichtenmit einem bestimmten Bit. Naturlich mussen dabei Sender und Empfanger denUbertragungsvorgang mit dem gleichen Bit beginnen. Nehmen wir an, dass sie beideabgestimmt mit

”1“ beginnen, so dass zunachst bs = 1 und br = 1 gilt.

Der Empfanger uberpruft bei jeder empfangenen Nachricht, ob das Bit mit demerwarteten ubereinstimmt. Wenn ja, gibt er die Nachricht weiter nach außen uberden Kanal r und sendet das Bit uber den Bestatigungskanal c3 an den Sender zuruck;wenn das Bit nicht dem erwarteten entspricht, ignoriert der Empfanger die Nachricht(da er davon ausgehen muss, dass es sich um eine Kopie einer bereits empfangenenNachricht handelt) und sendet das Bit der Nachricht uber den Bestatigungskanal,um dem Sender mitzuteilen, dass die Nachricht (erneut) eingegangen ist. Die Kom-ponentensicht auf den Empfanger ist im Abb. 1.6 gegeben.

Receiver

br : Bitc3 : Bit

r : Data

c2 : Data × Bit

Abb. 1.6.: Komponentensicht auf den Empfanger

Wir konnen das Verhalten des Empfangers auch durch ein Paar von Funktionenuber den Sequenzen der Ein- und Ausgabenachrichten beschreiben:

r = f(c2,1)c3 = g(c2)

wobei (fur die genauere Erlauterung der Notation siehe spater) gelte (hier bezeichnetab die Konkatenation der Sequenzen a und b – fur Details siehe spater):

12 18. Marz 2014


g(〈m(d, t)〉c2) = 〈t〉g(c2)f(〈m(d, t)〉c2, t) = 〈d〉f(c2, ¬t)f(〈m(d, t)〉c2, ¬t) = f(c2, ¬t)

Diese Gleichungen beschreiben, dass der Strom der Bit-Anteile uber das zweite Me-dium zuruckgeschickt wird und als Ergebnis der Strom bestehend jeweils aus denNachrichten bei Wechsel der Bits geschickt wird. Das Verhalten des Empfangerswird in Abb. 1.7 alternativ in Form eines Zustandsubergangsdiagramms mit Ein-und Ausgabe beschrieben.

Ein Ablauf des Ubertragungsvorgangs kann anschaulich durch ein Ereignisdia-gramm dargestellt werden. Wir stellen Ablaufe mit Hilfe von so genannten Nach-richtensequenzdiagrammen (Message Sequence Chart, MSC, vgl. [Bro91]) dar, einemITU-Standard1 der im Zusammenhang mit der Beschreibungssprache SDL entstand,siehe [Bro91] und spater Eingang in die UML gefunden hat.

Receiving

{br = t} c2 : m(d,t) / r : d, c3 : t {br := ¬t}

{br = ¬t} c2 : m(d,t) / c3 : t {br := 1}

Abb. 1.7.: Zustandsubergangssicht des Empfangers in Form eines Zustandsubergangsdiagramms

Abb. 1.8 gibt die erfolgreiche Ubertragung einer Nachricht ohne Nachrichtenver-lust durch ein MSC wieder. Jede Komponente wird durch eine vertikale

”Lebenslinie“

dargestellt. Die horizontalen Pfeile symbolisieren einzelnen Nachrichtenaustauschund einhergehende Zustandsubergange. Abb. 1.9 beschreibt den Fall der erfolglosenUbertragung. Abb. 1.10 zeigt die erfolgreiche Ubertragung mit erfolgloser Ruck-bestatigung. Abb. 1.11 zeigt die Situation der erfolgreichen Ruckbestatigung einervorher erfolgten erfolgreichen Ubertragung.

1The International Telecommunication Union

18. Marz 2014 13


Sender Medium1 Receiver

x : e

c2 : m(d,b)

r : d

{b = br} br := ¬brc1 : m(d,b)

Medium2

bs = b

d := e

c4 : b

c3 : b

br = b

bs := ¬bs

br = ¬bbs = ¬b

Abb. 1.8.: Message Sequence Chart (wie in SDL): Szenario fur erfolgreiche Ubertragung


x : e

c1 : m(d,b)

Medium2

bs = b

d := e

br = b

br = bbs = b

Abb. 1.9.: Szenario: Erfolglose Ubertragung

Die MSCs zeigen exemplarische Interaktionsmuster (Szenarien) fur das betrachteteSystem. Sie definieren damit das Verhalten jeder betroffenen Komponente in derRegel nicht vollstandig, zeigen aber anschaulich beispielhaft wie diese zusammen-wirken.

Die in Abb. 1.12 wiedergegebene Form der Darstellung von Prozessen ist an dieEntwurfssprache Grapes angelehnt (siehe [Hel91]). Ahnliche Beschreibungen findensich in betriebswirtschaftlichen Anwendungen, bei denen Prozesse darzustellen sind.Typische Beispiele fur Prozessdarstellungen finden sich in ARIS, einer Prozessbe-schreibungssprache nach Scheer zur Beschreibung von betriebswirtschaftlichen Pro-zessen im Umfeld des Softwaresystems SAP R/3 (vgl. [SJ02] und [Sei02] oder in denArbeiten von Linz [BSL99]).

14 18. Marz 2014



x : e

c2 : m(d,b)

r : d

{b = br} br := ¬brc1 : m(d,b)

Medium2

bs = b

d := e

c3 : b

br = b

br = ¬bbs = b

d = e

Abb. 1.10.: Szenario: Erfolgreiche Ubertragung - erfolglose Ruckbestatigung


c2 : m(d,b)

c1 : m(d,b)

Medium2

bs = b

d = e

c4 : b

c3 : b

bs := ¬bs

br = ¬bbs = ¬b

br = ¬b

Abb. 1.11.: Szenario: Erfolgreiche erneute Ubertragung - erfolgreiche Ruckbestatigung

Das Beispiel, so einfach es ist, zeigt bereits die Komplexitat und Vielschichtigkeitvernetzter, verteilter Systeme und ihrer Modellierung. Im folgenden werden wir aufdiese Aspekte in allen Details eingehen.

18. Marz 2014 15



r : d

c1 : m(d,b)

Medium2

bs = b

d := e

c4 : b

c3 : b

bs := ¬bs

br = ¬bbs = ¬b

br = b

x : e

c2 : m(d,b)

br := ¬b

Abb. 1.12.: Prozessdiagramm (wie in GRAPES)

1.6. Geschichtliche Bemerkungen zur Entwicklung der

methodischen Grundlagen verteilter Systeme

Die Anfange des Gebietes der verteilten Systeme liegen in den 60er Jahren. Mitdem Aufkommen erster Betriebssysteme, mit der Nutzung von Rechnersystemen,die teilweise miteinander vernetzt sind, mit dem Einsatz von Rechnersystemen alseingebettete Systeme wurden erstmals Fragen der Koordination und Synchronisationvon Programmen als wesentliche Fragestellung erkannt. Bahnbrechende Pionierar-beiten sind die Beitrage von Carl Adam Petri (vgl. [Pet63]), von Edsger Dijkstra(vgl. [Dij65]) mit seinem Vorschlag der Semaphore, die Ansatze zum Coroutinen-Konzept in Simula 67 von Ole Johan Dahl und Kristen Nygaard (vgl. [DN65]) undschließlich Arbeiten von C.A.R. Hoare unter dem Stichwortern

”Monitore“ und

”be-

dingte kritische Bereiche“(vgl. [Hoa74]), aber auch Beitrage von einer Reihe andererWissenschaftler wie Per Brinch Hansen (vgl. [Han78] und [Han87]) und vielen an-deren.

Jedoch bereits lange bevor die Aufmerksamkeit der internationalen Informatik aufdiese Themenstellung gefallen ist, namlich Anfang der 60er Jahre hat Carl AdamPetri mit seiner Dissertation (vgl. [Pet62]) das Gebiet der Petrinetze begrundet.Petrinetze sind ein sehr fundamentaler Ansatz zur abstrakten Beschreibung vonNebenlaufigkeit und Synchronisationsaspekten.

16 18. Marz 2014

1.6. Geschichtliche Bemerkungen zur Entwicklung der methodischen Grundlagenverteilter Systeme

Doch erst Ende der 60er Jahre findet das Thema, ausgelost von Frage bei der Ge-staltung von Betriebssystemen, breitere Aufmerksamkeit. Die Arbeiten von Dijkstra,Dahl und Hoare schaffen weitere Grundlagen.

Die 70er Jahre sind gekennzeichnet durch eine Reihe grundlegender Uberlegungen,welche Sprachkonstrukte zur Beschreibung von Nebenlaufigkeit und der Interakti-on zwischen nebenlaufigen Programmen am besten geeignet sind. Dabei sind dieLosungen noch stark durch die Idee des Zentralrechners gepragt, auf dem mehrereProgramme zeitlich verschrankt zur Ausfuhrung gelangen (Multiprogrammierung),dabei teilweise auf gemeinsamem Speicher arbeiten und in dieser Hinsicht zu syn-chronisieren sind. Die Sprachkonstrukte, die dazu entwickelt worden sind, sind maß-geblich von dieser Vorstellung gepragt.

Spater lost sich das Gebiet von dieser stark am Zentralrechner orientierten Vorstel-lung und widmet sich einer allgemeinen Modellierung von nebenlaufigen Prozessen,die miteinander kommunizieren. Herauszuheben sind wieder Arbeiten von C.A.R.Hoare zum Thema

”Communicating sequential processes“ – CSP (vgl. [Hoa85a])

und von Per Brinch Hansen (vgl. [Han78]). Parallel dazu entsteht eine Fulle vonAnsatzen wie beispielsweise zur Untersuchung des Datenflusskonzeptes, ausgehendvon Uberlegungen von Jack B. Dennis (vgl. [Den74] und [DBkCL80]) und durchrichtungweisende Arbeiten von David MacQueen und Gilles Kahn (vgl. [KM77]), indenen sie zeigen, wie ein Netzwerk von kommunizierenden Prozessen uber Stromeund Gleichungen dafur modelliert werden kann. Auf diese Ansatze folgen eine Reihevon sprachlichen Untersuchungen und Vorschlagen, u. a. die ProgrammierspracheLucid von Ashcroft (vgl. [AW76]).

Robin Milner greift ahnliche Vorstellungen auf, wie sie in den Ansatzen von Hoarevorliegen (vgl. [Mil80], [Mil89] und [Mil99]). Allerdings sind seine Arbeiten starkergrundlagenorientiert. Er verfolgt eher die Linie der operationellen Semantik sol-cher Systeme und die Frage, wie man fur eine gegebene operationelle Semantik einegeeignete Kongruenzrelation findet, um ein semantisches Modell solcher Systemeanzugeben.

In den 80er Jahren wenden sich die Arbeiten starker der logischen Behandlung undmethodischen Themen zu. Wichtige Fragestellungen bei den Programmkonstruktensind geklart. Nun wird starker uber die Verifikation und die Beschreibung der Ei-genschaften von nebenlaufigen vernetzten Programmen nachgedacht. Es entstehenAnsatze wie temporale Logik (vgl. [vB91, BG93, Kro87, MP92] etc.), UNITY (vgl.[CM88]) und TLA2 (vgl. [Lam94]), die sich gleichermaßen zum Ziel machen, ver-netzte Systeme spezifizieren und verifizieren zu konnen. Mit den 90er Jahren ruckensolche Systeme durch die wachsende Bedeutung der Netze und eingebetteter Syste-me noch starker in die Aufmerksamkeit. Die Idee der Sichtmodellierung der Systemebeginnt sich deutlich abzuzeichnen.

Stark beeinflusst von objektorientierten Vorstellungen, aber auch von Uberlegun-gen aus der Telekommunikation, wie sie sich vor allem in der Modellierungssprache

2The Temporal Logic of Actions

18. Marz 2014 17


SDL (vgl. [Bro91]) wiederfinden, pragen immer starker die Vorstellungen einer mo-dellorientierter Darstellung verteilter Systemwerkzeuge entstehen, in denen solcheModellierungen direkt unterstutzt werden.

Parallel dazu werden neue Analysemethoden entwickelt. Sehr pragend ist dabeidas so genannte Modell Checking (vgl. [BVW94] und [CGP99]). Dies stellt eine Tech-nik dar, bei der fur eine endliche Zustandsmaschine mit einem moglicherweise sehrhochdimensionalen Zustandsraum alle Zustande auf bestimmte Eigenschaften uber-pruft werden. Wird der Zustandsraum mit besonderer Rafinesse kodiert, wird dasAbsuchen des Zustandsraums besonders geschickt organisiert, gelingt es Systeme aufdiese Weise zu untersuchen, die einen Zustandsraum mit sehr vielen Zustanden auf-weisen. Diese Technik wird schnell als interessant auch fur praktische Anwendungenerkannt und in ersten Experimenten auch praktisch eingesetzt.

Mit der UML (der Unified Modeling Language) ist heute ein Quasistandard furdie Modellierung von Systemen verfugbar, der mit großem kommerziellen Nachdruckin die breite Anwendung gebracht wird. Allerdings weist die UML einige Schwachenauf, die nicht zuletzt mit dem Umstand zu tun haben, dass der zugrundeliegen-de Modellierungsansatz aus einem etwas einseitigen Einsatz der Objektorientierungstammt und somit immer noch stark durch sequentielle Vorstellungen gepragt ist.Zweifellos ist aber die UML ein wichtiger Schritt in die Richtung auf eine umfangrei-che und weit verbreitete Modellierung verteilter Systeme. UML ist aber ohne jedenZweifel nur eine Stufe einer Treppe, die wir in den kommenden Jahrzehnten Schrittfur Schritt erklimmen werden. Modellierung und systematische Entwicklung verteil-ter diskreter Systeme werden in den nachsten 10 bis 20 Jahren eine der zentralenAntriebskrafte fur Hochtechnologie bleiben und noch starker werden.

1.7. UbungsaufgabenUbungsaufgabe 1.1: Uberlegen Sie die Konsequenz fur das Beispiel des Al-

ternating Bit Protokolls, wenn

a) Das Medium auch Nachrichten verdoppeln kann

b) Das Medium die Reihenfolge der Nachrichten verandern kann

Ubungsaufgabe 1.2: Zeigen Sie ein Interaktionsdiagramm fur die Bedienungeines Bankomaten fur das Beispiel der Geldentnahme.

18 18. Marz 2014

2. Zustandssicht: Systeme alsZustandsmaschinen

Ein weit verbreitetes, eingangiges Modell fur interaktive vernetze Systeme bildenZustandsubergangssysteme und Zustandsmaschinen (engl. State Transition Machi- Zustands-

maschineZM (STM)Automat

nes, STM s oder auch Automaten genannt). In der Informatik gibt es eine Viel-zahl von Varianten solcher Zustandsubergangsmaschinen, da viele Gesichtspunktevon Informatiksystemen anschaulich durch sie modelliert werden konnen. Rechnerund Schaltungen konnen durch Zustandsmaschinenmodelliert werden. ImperativeProgramme konnen als einfache Zustandsmaschinen verstanden werden. Zustands-maschinen mit Eingabe und Ausgabe modellieren die Ubergange (die Nachfolge-zustande) und Ausgaben interaktiver Systeme. Dadurch konnen auch Programmemit Ein- und Ausgabe als Zustandsmaschinen dargestellt werden.

Wir betrachten die folgenden drei Klassen unterschiedlicher Zustandsmaschinen:

� Zustandsubergangssysteme mit unmarkierten Ubergangen,

� Zustandsubergangssysteme mit Ubergangen markiert durch Aktionen,

� Zustandsubergangssysteme mit Ubergangen markiert durch Eingaben und Aus-gaben.

Auch prozedurale, zuweisungsorientierte Programme arbeiten uber Zustandsraumenund definieren Zustandsubergange. Wir erlautern spater den Zusammenhang zwi-schen Zustandsmaschinen und Ablaufen sowie den Zusammenhang zwischen Zu-standsubergangsmaschinen und anweisungsorientierten Programmen, sowie strom-verarbeitenden Funktionen. In diesem Zusammenhang betrachten wir auch anwei-sungsorientierte Programme und Nebenlaufigkeit. Zustandsmaschinen lassen sichanschaulich durch Zustandsubergangsdiagramme (engl. State Transition Diagrams, Zustands-

ubergangs-diagrammZUD (STD)

STDs) beschreiben. Wir behandeln auch eine Reihe solcher graphischer Darstellun-gen von Zustandsubergangssystemen.

2.1. Zustandsubergangssysteme

Das Verhalten eines verteilten Systems oder zumindest gewisse Aspekte seines Ver-haltens lassen sich anschaulich durch die Angabe einer Zustandsmenge (des

”Zu-

standsraums“) und der bei Systemablaufen stattfindenden Zustandsubergange be-schreiben. Bei dieser Art der Modellierung kommt der Wahl des Zustandsraums und

18. Marz 2014 19

Kapitel 2. Zustandssicht: Systeme als Zustandsmaschinen

dabei der Struktur der Zustande und der”Granularitat“ der Zustandsubergange her-

ausragende Bedeutung zu. Die Granularitat der Zustandsubergange bestimmt dieGroße der Schritte der Zustandsubergange und somit auch die Zahl und Eigenschaf-ten etwaiger Zwischenzustande.

2.1.1. Zustandsmaschinen mit unmarkierten Ubergangen

Wir betrachten im Folgenden Zustandsmaschinen, die einfachste Form von Zustands-maschinen.

Definition: Nichtdeterministische Zustandsmaschine (nichtdeterministischerZustandsautomat)nichtdetermi-

nistische(r)Zustands-maschine(Automat)

Eine nichtdeterministische Zustandsmaschine (∆, σ0) ist durch eine Zustandsmen-ge (engl. State) Σ, einen Anfangszustand σ0 ∈ Σ (oder eine Menge von Anfangs-zustanden Σ0 ⊆ Σ) und eine Zustandsubergangsfunktion

∆ : Σ→ ℘(Σ)

gegeben. Zusatzlich kann eine Menge Σω⊆Σ von Endzustanden vorgegeben sein.2

Zu jedem Zustand σ ∈ Σ gibt ∆(σ) die Menge der Nachfolgezustande zu σ an. Furσ′ ∈ ∆(σ) schreiben wir auch σ →∆ σ′ oder σ → σ′.

Wir geben zunachst ein erstes einfaches Beispiel fur eine Zustandsmaschine.

Beispiel 2.1: Zahler als ZustandsmaschineSei die Menge der Zustande durch die naturlichen Zahlen gegeben. Wir definierenalso den Zustandsraum Σcounter wie folgt:

Σcounter = N

Die Zustandsubergangsfunktion

∆counter : Σcounter → ℘(Σcounter)

sei gegeben durch die Gleichung

∆counter(x) = {x + 1}

Der Anfangszustande σ0 sei 0. Jeder Ubergang der Zustandsmaschine erhoht denZahler um eins. 2

Bei unserem Beispiel handelt es sich um eine totale, deterministische Zustandma-schine. Eine genaue Definition dieser Begriffe lautet wie folgt.

20 18. Marz 2014


Definition: Partielle, totale und (nicht)deterministische Zustandsmaschine partielletotale(nicht)determi-nistischeZM

Eine Zustandsmaschine (∆, σ0) heißt partiell, wenn gilt

∃σ ∈ Σ : ∆(σ) = ∅

Eine Zustandsmaschine (∆, σ0) heißt total, wenn gilt

∀σ ∈ Σ : ∆(σ) 6= ∅

Eine Zustandsmaschine (∆, σ0) heißt deterministisch, wenn gilt

|Σ0| ≤ 1 ∧ ∀σ ∈ Σ: |∆(σ)| ≤ 1

Eine Zustandsmaschine (∆, σ0) heißt nichtdeterministisch, wenn gilt

∃σ ∈ Σ: |∆(σ)| > 12

Auch zuweisungsorientierte Programme konnen durch Zustandsmaschinen darge-stellt werden. Dazu wahlen wir fur den Zustandsraum die Belegungen der Pro-grammvariablen (Datenzustand) und einen abstrakten Befehlszahler (Kontrollzu-stand). Wir stellen den Ubergang von einem zuweisungsorientierten Programm zueiner Zustandsmaschine spater im Detail dar.

Beispiel 2.2: Sortieren durch eine ZustandsmaschineWir betrachten folgenden Zustandsraum

Σsort = N∗ × N∗

Hier bezeichnet N∗ die Menge der endlichen Sequenzen von Zahlen. Ein Zustandist dann ein Paar (s, t) bestehend aus zwei Sequenzen s und t naturlicher Zahlen.Zum Beginn (im Anfangszustand) gelte s = 〈〉 und t sei eine beliebige Sequenz. DieZustandsmaschine erzeugt nach einer Folge von Ubergangen einen Zustand (s, 〈〉),wobei s die aufsteigende Sortierung der Sequenz t aus dem Anfangszustand ist. Wirdefinieren folgende Zustandsubergange:

∆sort(〈〉, 〈n〉 ◦ t) = {(〈n〉, t)}∆sort(s ◦ 〈n〉, 〈m〉 ◦ t) = if n > m then {(s, 〈m〉 ◦ 〈n〉 ◦ t)}

else {(s ◦ 〈n〉 ◦ 〈m〉, t)}fi

∆(s, 〈〉) = ∅

Wie oben bereits angesprochen fuhrt diese Zustandsmaschine vom Anfangszustand(〈〉, t) nach endlich vielen Schritten stets in einen Endzustand (s,〈〉) wobei s dieaufsteigend sortierte Sequenz zu t ergibt. 2

18. Marz 2014 21


Obwohl auch diese Zustandsmaschine noch vergleichsweise einfach ist, ist die Kor-rektheit ihrer Funktionsweise alles andere als offensichtlich. Spater werden wir Me-thoden behandeln, die die Korrektheit solcher Zustandsmaschinen zu beweisen er-lauben.

Fur eine Zustandsmaschine (∆, σ0) heißt eine Folge

σ0 → σ1 → σ2 → σ3 → . . .

eine Berechnung wobei δi → δi+1 fur die Aussage δi+1 ∈ ∆(δi) steht. Die Folgeσ0, σ1, σ2, . . . heißt dann auch Berechnungssequenz.Berechnung

Eine Zustandsmaschine erzeugt eine Menge von Berechnungssequenzen. Jede Be-rechnungssequenz ist eine endliche oder unendliche Folge von Zustanden, in unse-rer Terminologie sprechen wir auch von Stromen von Zustanden, von Spuren oderAblaufen.

Definition: Berechnungen, Spuren und Ablaufe einer ZustandsmaschineSpurAblaufHistorie

Eine Spur oder auch ein Ablauf einer Zustandsubergangsmaschine (∆, σ0) uber derZustandsmenge Σ ist eine endliche oder eine unendliche Folge von Zustanden

σ0, . . . , σn bzw. σ0, σ1, σ2, . . .

ab dem Startzustand so dass σi+1 ∈ ∆(σi) fur alle i < n bzw. fur alle i. Die Langeeines Ablaufes wie oben ist die Anzahl der Schritte n bzw. ∞. 2

Eine Zustandsubergangsmaschine definiert damit eine Menge von Ablaufen in derForm von Stromen (endlichen oder unendlichen Sequenzen) von Zustanden.

Eine besondere Rolle spielt fur Zustandsmaschinen die Menge der von einer gege-benen Menge Σ0 von Anfangszustanden aus erreichbaren Zustande. Mathematischausgedruckt erhalten wir fur die Transitionsfunktion

∆ : Σ→ ℘(Σ)

und die Menge Σ0 ⊆ Σ von Anfangszustanden die Menge R∆ ⊆ Σ der erreichbarenZustande durch folgende Charakterisierung: R∆ erfullt die Formel fur R

R ⊇ Σ0 ∪⋃σ∈R

∆(σ) (2.1)

wobei R∆ die kleinste Menge sei, die die Gleichung 2.1 erfullt.Hier handelt es sich um eine induktive Definition und um eine Hullenbildung. Ein

Zustand liegt in der Menge der erreichbaren Zustande, wenn er

(0) in der Menge der Anfangszustande Σ0 enthalten ist,

(1) von einem erreichbaren Zustand aus erreichbar ist.

22 18. Marz 2014


Man beachte, dass es neben R∆, der Menge der erreichbaren Zustande, noch weitereMengen R1, R2 , . . . geben kann, die die Formel 2.1 erfullen. Fur diese Mengen giltstets, dass sie R∆ als Teilmenge enthalten.

Die Menge der erreichbaren Zustande lasst sich auch direkt induktiv charakterisie-ren. Dazu konstruieren wir eine Folge von Mengen von Zustanden Σ0,Σ1, . . . wobeiΣ0 die Menge der Anfangszustande und Σi+1 fur i ∈ N durch die folgende Gleichunginduktiv definiert wird

Σi+1 = {σ′ ∈ ∆(σ) : σ ∈ Σi}

Anschaulich gesprochen ist Σi die Menge der Zustande, die von Σ0 in hochstens iZustandsubergangen zu erreichen sind.

Nun konnen wir die Menge der erreichbaren Zustande wie folgt spezifizieren

R∆ =⋃i∈N

Σi (2.2)

Wir fassen diese Argumente in ein Theorem zusammen.

Theorem:Fur jede Zustandmaschine (∆,Σ0) mit Zustandsubergangsfunktion

∆ : Σ→ ℘(Σ)

und die Menge Σ0 ⊆ Σ von Anfangszustanden existiert eine Menge R ⊆ Σ, die dieGleichung 2.1 erfullt. In der Menge der Losungen von 2.1 ist R∆ die im Sinne derMengeninklusion kleinste.

Beweis:Wie in 2.2 definiert, erfullt R∆ die obige Formel 2.1. Der Beweis ergibt sich wie folgt:Σ0 ⊆ R∆ gilt trivialerweise. Sei σ ∈ R∆, dann existiert ein i ∈ N mit σ ∈ Σi, danngilt ∆(σ) ⊆ Σi+1 und somit ∆(σ) ⊆ R∆.

Umgekehrt gilt: Erfullt eine Menge R′ die obige Formel 2.1, dann gilt R∆ ⊆ R′. Wirzeigen unschwer durch Induktion uber i ∈ N, dass Σi ⊆ R′.

Fur i = 0 gilt offensichtlich die Gleichung 2.1:

Σ0 ⊆ R′

18. Marz 2014 23


Gilt Σi ⊆ R′, dann erhalten wir

Σi+1

=⋃σ∈Σi

∆(σ)

⊆⋃σ∈R′ ∆(σ)

⊆ Σ0 ∪⋃σ∈R′ ∆(σ)

⊆ R′

Also gilt

R∆ =⋃i∈N

Σi ⊆ R′

2

Mit ahnlicher Argumentation lasst sich zeigen, dass σ ∈ R∆ genau dann gilt, wennein endlicher Ablauf σ0, . . . , σn existiert mit σ0 ∈ Σ0 und σn = σ.

Beispiel 2.3: Ampel – Erreichbare ZustandeBetrachten wir ein System fur einen Fußgangerubergang mit zwei Ampeln: Eine furAutos und eine fur Fußganger. Wir definieren mit der Zustandsmaschine Ampel1eine Ampel fur Autos. Zunachst spezifizieren wir den Zustandsraun Σ1, den An-fangszustand σ1

0 und die Ubergangsfunktion ∆1

Σ1 = {red, yellowred, yellow, green}σ1

0 = {green}

∆1(σ) =

{yellow} falls σ = green

{green} falls σ = yellowred

{red} falls σ = yellow

{yellowred} falls σ = red

Jetzt definieren wir als Zustandsmaschine Ampel2 eine Ampel fur Fußganger.

Σ2 = {stop, go}σ2

0 = stop

∆2(σ) =

{{go} falls σ = stop

{stop} falls σ = go

24 18. Marz 2014


Das System Ampel, die beide Ampeln, Ampel1 und Ampel2, komponiert, hat folgen-den Zustandsraum:

Σ = {(σ1, σ2) : σ1 ∈ Σ1 ∧ σ2 ∈ Σ2}

σ0 = {(green, stop)}

∆(σ) =

{(green, stop)} falls σ = (yellowred, stop),

{(red, stop)} falls σ = (red,go),

{(yellowred, stop)} falls σ = (red, stop),

{(yellow, stop)} falls σ = (green, stop),

{(red,go)} falls σ = (yellow, stop),

∅ sonst.

Der Zustand (green, go) sollte aus offensichtlichen Grunden auf jeden Fall unerreich-bar sein. Aus Sicherheitsgrunden sind auch die Zustande (yellow, go) und (yellowred,go) besser nicht erreichbar.

Die Menge der erreichbaren Zustande ist gegeben durch

R∆ = {(green, stop), (red, stop), (yellowred, stop), (yellow, stop), (red,go)}

Die Zustandsdiagramme fur die Zustandsmaschinen Ampel1, Ampel2 und Ampel sindin der Abb. 2.1, 2.2 und 2.3 gegeben. 2

yellow

redgreen

yellowred

Abb. 2.1.: Zustandsubergangsdiagramm fur Maschine Ampel1

Mengen von Zustanden lassen sich einfach uber Zusicherungen charakterisieren. EineZusicherung ist ein Pradikat p : Σ→ B.

Neben der Menge der erreichbaren Zustande sind fur die Analyse von Zustandsuber-ganssystemen auch Zustandsmengen von Interesse, die die Menge der erreichbarenZustande als Teilmenge enthalten. Diese lassen sich durch so genannte Invariantencharakterisieren. Eine Reihe von Eigenschaften von Spuren von Zustanden konnenwir uber solche invariante Zusicherungen beschreiben.

18. Marz 2014 25


gostop

Abb. 2.2.: Zustandsubergangsdiagramm fur Maschine Ampel2

(yellow,stop)

(red,go)(green,stop)

(yellowred,stop) (red,stop)

Abb. 2.3.: Zustandsubergangsdiagramm fur Maschine Ampel

Definition: Zustandsinvariante Zustands-invarianteEin Pradikat auf Zustanden

p : Σ→ B

heißt Zustandsinvariante einer Zustandsmaschine, wenn Pradikat p fur alle erreich-baren Zustande gilt. 2

Sei R∆ die Menge der erreichbaren Zustande. Das Pradikat

σ ∈ R∆

ist dann trivialerweise eine Invariante. Sicherheitsbedingungen lassen sich oft sehranschaulich durch Invarianten beschreiben.

Der Nachweis, dass ein Zustandspradikat eine Invariante ist, lasst sich uber stabilePradikate fuhren.

Definition: Stabiles PradikatstabilesPradikat Ein Pradikat auf Zustanden

p : Σ→ B

26 18. Marz 2014


heißt fur eine Zustandsubergangsfunktion ∆ stabil, falls die folgende Aussage furalle Zustande σ und σ′ gilt:

p(σ) ∧ σ′ ∈ ∆(σ) ⇒ p(σ′).

2

Zustande, die das stabile Pradikat erfullen, werden durch Zustandsubergange stetsin Zustande uberfuhrt, die das Pradikat ebenfalls erfullen.

Ist eine Zusicherung fur eine Zustandsmaschine stabil, so gilt die Zusicherung injeder Spur fur alle Folgezustande, sobald sie fur einen Zustand gilt.

Theorem: Zusammenhang Stabilitat und InvarianzSei p : Σ→ B ein Pradikat auf dem Zustandsraum Σ der Zustandsmaschine (∆, σ0),dann gilt: Ist p stabil und gilt fur den Anfangszustand σ0, dann ist p eine Invariantefur (∆, σ0).

Beweis:Zu zeigen ist, dass p fur alle Zustande σ ∈ R gilt. Da nach 2.2 R∆ =

⋃i∈N Σi gilt mit

Σ0 = {σ0}, genugt es zu zeigen, dass p(σ) fur alle σ ∈ Σi gilt mit i ∈ N.Fur i = 0 gilt p(σ0) nach Voraussetzung.Gilt p(σ) fur alle σ ∈ Σi, dann gilt aufgrund der Stabilitat von p die Aussage

p(σ′) fur alle σ′ ∈ ∆(σ) und damit fur Σi+1 =⋃σ∈Σi

∆(σ) 2

Es genugt also der Nachweis der Stabilitat eines Pradikates p und seiner Gultigkeitfur die Anfangszustande, um sicher zu sein, dass p Invariante ist, also fur alle er-reichbare Zustande gilt.

Beispiel 2.4: Stabiles Pradikat fur Zahler als ZustandsmaschineFur den Zahler als Zustandsmaschine ist fur jede Zahl n die Zusicherung σ ≥ nstabil, aber nur fur n = 0 eine Invariante. 2

Stabile Pradikate und Invariante sind ein wichtiges Mittel der Analyse und Verifi-kation von Eigenschaften von Zustandsmaschinen.

Eine Zustandsinvariante ist ein Zustandspradikat, das fur alle erreichbaren Zustande(und damit naturlich fur alle Anfangs-, Zwischen- und Endzustande) gilt. Sei R∆ dieMenge der erreichbaren Zustande einer Zustandsmaschine. Das Pradikat

p : Σ→ B

definiert durch die Gleichung

p(σ) = (σ ∈ R∆)

18. Marz 2014 27


ist die starkste Invariante (das starkste Pradikat), das fur alle erreichbaren Zustandegilt. Ein Pradikat

q : Σ→ B

ist genau dann eine Invariante, wenn q fur jeden erreichbaren Zustand σ gilt, alsowenn fur alle Zustande σ ∈ Σ:

p(σ)⇒ q(σ)

gilt. Eine Methode nachzuweisen, dass Pradikat q eine Invariante ist, besteht darin,nachzuweisen, dass

q fur alle Anfangszustande giltq stabil ist.

Wir demonstrieren das an einem einfachen Beispiel.

Beispiel 2.5: Zustandsmaschine mit InvarianteAbb. 2.4 beschreibt eine einfache Zustandsmaschine durch ein Zustandsubergangs-diagramm. Fur sie gilt folgende Invariante:

Inv ≡ (x + y = m)

axy axay

{x + y = m, x > 0, y > 0}

{x = 1} x, y := 0, y +1

x, y := 1, y - 1

{y = 1} x, y := x+1, 0

x, y := x -1, 1{x > 1} x, y := x - 1, y + 1{y > 1} x, y := x + 1, y - 1

Abb. 2.4.: Zustandsmaschine (sei m ∈ N, m > 1)

Die Kontrollzustande lassen sich dabei durch Zusicherungen wie folgt charakterisie-ren:

ay ≡ (x = 0 ∧ Inv)

ax ≡ (y = 0 ∧ Inv)

axy ≡ (x > 0 ∧ y > 0 ∧ Inv)

28 18. Marz 2014


Es ist einfach nachzuweisen, dass die Invariante zu Beginn (fur den Anfangszu-stand) gilt und stabil ist.

2

Eine fundamentale Methode, eine Zusicherung q, die nicht stabil ist, als Invariantenachzuweisen, besteht darin, eine zweite Invariante (etwa q′) zu finden, die stabilist. Fur diese ist dann zu zeigen, dass sie stabil ist und q′ im Anfangszustand giltund zusatzlich fur alle Zustande σ

q′(σ) =⇒ q(σ)

nachzuweisen. Schwierig ist dabei allerdings oft das Finden der geeigneten stabilenInvariante.

Wir geben nun ein Beispiel fur eine Invariante, die nicht stabil ist, und den Nach-weis der Invarianteneigenschaft uber eine geeignete stabile Zusicherung.

Beispiel 2.6: Instabile InvarianteWir betrachten den Zustandsraum Σ = Z mit Anfangszustand σ0 = 0 und derUbergangsfunktion ∆ so, dass gilt

∆(σ) = {σ + 2} falls σ gerade Zahl∆(σ) = {−σ} falls σ ungerade Zahl

Die Zusicherung p(σ) = (σ ≥ 0) ist Invariante, aber nicht stabil, da etwa

∆(9) = {−9}gilt. Der Nachweis, dass p Invariante ist, erfolgt etwa uber die Zusicherung q:

q = (σ gerade und σ ≥ 0)

Wie wir unschwer zeigen gilt: q ist stabil und gilt fur den Anfangszustand und weitergilt fur alle σ ∈ Σ:

q(σ) =⇒ p(σ) 2

Eine ausfuhrliche Theorie und Methodik zur Behandlung unmarkierter Zustandsuber-gangssysteme findet sich unter dem Stichwort UNITY in [CM88]. Dort werden dieZustande durch Belegungen von Programmvariablen mit folgenden Sorten darge-stellt und die Zustandsubergange durch bedingte Zuweisungen.

Die Zustandsubergange bestehen dann aus einer Menge bedingter Anweisungender Form

if Bedingung then x1, . . . , xn := E1, . . . , Enelse nop

fi

Fur jeden Zustandsubergang wird nichtdeterministisch eine Anweisung ausgefuhrt.Zusatzlich gilt eine Fairnessbedingung. Jede Anweisung wird unendlich oft aus-gewahlt. Da stets unendliche Ablaufe betrachtet werden, ist diese Forderung immererfullbar.

18. Marz 2014 29


2.1.2. Zustandsmaschinen mit markierten Ubergangen

In Zustandsmaschinen, wie wir sie bisher betrachtet haben, wird zu gegebenenZustanden die Menge der Nachfolgezustande festgelegt. Die Frage, durch was einZustandsubergang ausgelost wird, wird nicht betrachtet. Nun betrachten wir furdie Modellierung von Systemen eine Menge von Aktionen und eine Menge vonZustanden. Es wird beschrieben, wie sich Aktionen als Zustandsanderungen aus-wirken. Ein einfaches Beispiel fur Aktionen sind die Anweisungen etwa in Program-miersprachen. Die Ausfuhrung einer Anweisung entspricht einem Zustandsubergang.

Definition: Nichtdeterministische Zustandsmaschine mit markiertenUbergangennichtdetermi-

nistischeZM mitmarkiertenUbergangen

Eine nichtdeterministische Zustandsmaschine (∆, A, σ0) ist durch eine Zustands-menge Σ, eine Aktionsmenge A, einen Anfangszustand σ0 ∈ Σ (oder eine Menge vonAnfangszustanden Σ0 ⊆ Σ) und eine Zustandsubergangsfunktion

∆a : Σ→ ℘(Σ)

fur jede Aktion a ∈ A gegeben. 2

Wir schreiben fur die Aussage σ′ ∈ ∆a(σ) oft auch anschaulich

σa−→ σ′

Eine Aktion ist nicht notwendigerweise in jedem Zustand ausfuhrbar.Eine Aktion a ∈ A heißt bereit (engl. enabled) im Zustand σ ∈ Σ, falls im Zustandbereite

Aktion(enabled)

σ ein Zustandsubergang durch Ausfuhrung der Aktion a moglich ist. Genau danngilt die Aussage:

∆a(σ) 6= ∅

Wir schreiben dann auch die Aussage

enabled(a, σ).

Zustandsmaschinen mit markierten Ubergangen konnen anschaulich zur Modellie-rung von sequentiellen, anweisungsorientierten Programmen verwendet werden. DerMenge der Aktionen entsprechen die Anweisungen. Man beachte, dass Anweisungenin sequentiellen Programmen immer genau dann ausfuhrungsbereit sind, wenn derKontrollzahler in der entsprechenden Position ist. Neben Programmen konnen wirauch den interaktiven Zugriff auf Datenstrukturen, etwa auf Datenbanken, durchZustandsubergangsmaschinen modellieren.

Wir geben zunachst ein einfaches Beispiel.

30 18. Marz 2014


Beispiel 2.7: Keller als Zustandsmaschine mit markierten UbergangenSei die Menge Data von Datenelementen gegeben. Ein Keller (engl. Stack) kannAktionen aus folgender Menge Astack von Aktionen ausfuhren:

Astack = {initStack, pop} ∪ {top(d) : d ∈ Data} ∪ {push(d) : d ∈ Data}

Die Menge der Zustande der Maschine definieren wir in unserem Beispiel durchfolgende Festlegung:

Σ = Data∗

Data∗ beschreibt die Menge der endlichen Sequenzen mit Elementen aus Data. DieZustandsubergangsfunktion

∆a : Σ→ ℘(Σ)

definieren wir fur die Aktionen a ∈ Astack durch folgende Gleichungen (hier beschreibt

”◦“ die Konkatenation von Sequenzen):

∆initStack(s) = {〈〉}∆pop(s) = {s′ : ∃d ∈ Data : s = 〈d〉 ◦ s′}∆push(d)(s) = {〈d〉 ◦ s}∆top(d)(s) = {s : ∃s′ ∈ Data∗ : s = 〈d〉 ◦ s′}

Hier modellieren wir den Keller so, dass die Operationen pop und top(d) nur ausfuhr-bar sind, wenn der Keller nicht leer ist. top(d) ist nur ausfuhrbar, wenn d das nachsteElement in der Warteschlange ist. 2

Der Keller aus obigem Beispiel laßt sich nicht ohne weiteres direkt als Zustandsuber-gangsdiagramm darstellen, da der Zustandsraum nicht endlich ist. Fuhren wir je-doch Pradikate auf den Zustanden ein, wie etwa die Pradikate nonempty und empty,die den Zustandsraum in eine endliche Menge von Aquivalenzklassen1 unterteilen,dann konnen wir den Keller wie in Abb. 2.5 gezeigt als Zustandsubergangsdiagrammdarstellen. Man beachte, dass das Pradikat nonempty eine unendliche Menge vonZustanden beschreibt.

Die Knoten in dem Ubergangsdiagramm nennen wir auch Kontrollzustande. Sieentsprechen Zusicherungen und dienen auch der strukturierten Beschreibung, wannein Ubergang transitionsbereit ist.

Dabei beschreibt die Markierung

{Q} a {R}

1Eine Aquivalenzklasse ist eine Teilmenge des Zustandsraums mit bzgl. eines Pradikats gleichenEigenschaften.

18. Marz 2014 31


eine Menge von Zustandsubergangen σ′ ∈ ∆a(σ8) als Ubergangsregel

Q ∧ R =⇒ σ′ ∈ ∆a(σ8)

Hier bezeichnet σ′ den Zustand nach dem Zustandubergang und σ8 den Zustand vordem Zustandsubergang. Q heißt der Wachter der Ubergangsregel.

Stack_nonemptyStack_empty

initStack {s´ = ‹ › }

push(d) {s´ = ‹d› ○ s`}

{first(s`) = d} top(d) {s´ = s`}{#s` = 1} pop {s´ = ‹ › }

push(d) {s´ = ‹d› ○ s` }

{#s` > 1} pop {s´ = rest(s`)}

Abb. 2.5.: Zustandsubergangsdiagramm fur Keller

Werden Q oder R nicht explizit aufgefuhrt, so entsprechen sie der Aussage”true“.

Betrachten wir die Kontrollzustande markiert mit den Zusicherungen K und K′, wirddie Kante

K′K

{Q} {R}

in die Zustandsubergangsregel

K ∧ Q ∧ R ∧ K′ =⇒ σ′ ∈ ∆a(σ8)

ubersetzt.

32 18. Marz 2014

2.2. Logische Modellierung von Zustandsmaschinen

2.1.3. Zustandsubergangsdiagramme

Es ist oft hilfreich und anschaulich, Zustandsubergangssysteme mit markierten Ubergangendurch Zustandsubergangsdiagramme darzustellen. Abb. 2.5 gibt ein erstes Beispieldafur. Es beschreibt den Keller als Zustandsmaschine durch ein Zustandsubergangs-diagramm.

Definition: Zustandsubergangsdiagramm Zustands-ubergangs-diagrammZUD

Ein Zustandsubergangsdiagramm ist ein gerichteter, markierter Graph. Seine Knotenheißen Kontrollzustande und charakterisieren Mengen von Zustanden des Zustands-raums. Seine Kanten heißen Zustandsubergange. Die Knoten konnen Zusicherungenenthalten, die die Zustande beschreiben, die in diesen Knoten eingenommen werdenkonnen. Die Kanten werden mit Aktionen a als Marken versehen. Zusatzlich kannzu jeder Marke ein Paar logischer Pradikate

(Q(σ), R(σ, σ′))

angegeben werden, die uber die Vorbedingung (”Wachter“) Q festlegen, in welchem

Zustand σ die Aktion a ein Ubergang auftreten kann und uber die NachbedingungR festschreiben wie sich der Zustand σ durch den Ubergang in einen Zustand σ′

verandert. Ein Knoten kann durch einen Extra-Pfeil mit schwarzem Punkt am An-fang als Anfangszustand gekennzeichnet sein. 2

Zustandsubergangsdiagramme sind in der theoretischen Informatik fur endliche Au-tomaten zur Definition von formalen Sprachen verbreitet und in der Praxis um dasVerhalten von Systemen strukturiert darzustellen.


Bei Zustandsmaschinen treten oft charakteristische Mengen von Zustanden auf, wieetwa die Menge der erreichbaren Zustande oder die Menge der Anfangszustande.Mengen von Zustanden lassen sich gut durch Pradikate (Zusicherungen) charakteri-sieren. Sind Zustande Belegungen von Zustandsattributen, die durch Identifikatoren(Variable) gegeben sind, so lassen sich diese Pradikate einfach als pradikatenlogischeAusdrucke uber diesen Identifikatoren, genannt Zusicherungen, formulieren.

2.2.1. Zustande als Variablenbelegungen

Sei V eine Menge von sortierten (getypten) Identifikatoren (Programmvariablen,Attributen) und die Menge Σ der Zustande gegeben durch (sei M das Universumder Datenwerte) die Menge der Abbildungen von Attributen auf Werte in M:

Σ = {σ : V→ M}

18. Marz 2014 33


Sind fur die Attribute Sorten festgelegt, so fordern wir, dass in allen Zustanden dieBelegung der Attribute diesen Sorten entspricht. Jedes Pradikat

p : Σ→ B

kann dann durch eine pradikatenlogische Formel uber dem Zustandsraum Σ be-schrieben werden (B bezeichnet hier die Menge {true, false}). Wir sprechen vonZusicherungen. Durch diese Technik konnen auch die Menge der Anfangszustandeoder die Menge der erreichbaren Zustande mit logischen Mitteln beschrieben wer-den.

Beispiel 2.8: Zustandsraum als Belegung von AttributenWir betrachten den Zustandsraum zur Beschreibung des Zustands eines Fahrzeugs.Wir betrachten die folgenden Attribute:

handbremse ∈ Bgeschwindigkeit ∈ Ngang ∈ Nblinker ∈ {aus, links, rechts, warnblink}beleuchtung ∈ {aus, park, abblend, aufblend}

Die Menge der typisierten Attribute definiert uber die Belegungen einen Zustands-raum. Eine Zusicherung kann dann beispielsweise wie folgt formuliert werden:

gang > 2⇒ geschwindigkeit > 30 ∧ ¬handbremse

Dieser Ausdruck definiert ein Pradikat auf Zustanden. Ein Zustand entspricht einerBelegung der Attribute. 2

Umfangreiche Zustandsraume konnen ubersichtlich durch E/R-Diagramme beschrie-ben werden. Dies gilt insbesondere fur Datenbanken. Jeder Zustand entspricht danneiner Entitatsmenge fur jede Entitat und Relationen zwischen diesen Mengen furjede Beziehung.

Im Prinzip konnen wir fur die Attribute beliebige Signaturen Σ und entspre-chend Σ-Algebren verwenden, um Zustande darzustellen. Die Signatur definiert dieAttribute und ihre Sorten. Auch Funktionen sind als Attribute zugelassen. Dannentspricht der Zustandsraum einer Menge von Σ-Algebren. Jede Algebra entsprichteinem Zustand. Diese Idee liegt auch dem Ansatz der

”evolving Algebras“ oder ab-

strakten Zustandsmaschinen zugrunde (siehe [Gur94] und [BG94]).

2.2.2. Kontrollzustande als Pradikate inZustandsubergangsdiagrammen

Die Knoten eines Zustandsubergangsdiagramms (ZUDs) stehen fur Kontrollzustande.Jeder Kontrollzustand kennzeichnet eine Teilmenge von Datenzustanden der Maschi-ne, die auch durch eine Zusicherung charakterisiert werden kann.

34 18. Marz 2014


Ein Zustandsubergangsdiagramm mit Markierungen wie in Abb. 2.6 beschrieben,wobei Q eine Bedingung fur den Ausgangszustand ist, S eine Aktion (die einer Anwei-sung uber dem Zustandsraum entspricht) und R eine Bedingung uber den Ausgangs-und den Zielzustand, entspricht einem Zustandstransitionssystem und damit aucheinem anweisungsorientierten Programm. In manchen Fallen, wenn wir keine Ein-schrankungen der Ubergange durch Vor- oder Nachbedingung brauchen, durfen dieseauch weggelassen werden, dies ist gleichwertig mit der Zusicherung true.

Abb. 2.6 beschreibt eine Zustandsubergangsregel in einem Zustandsubergangsdia-gramm. Ist die Zustandmaschine in einem durch den Startknoten k gekennzeichne-ten Ausgangszustand und gilt die Bedingung Q, so ist der Ubergang zum Knoten k′

moglich. Dazu wird die Anweisung S ausgefuhrt und ein Zielzustand in dem durchden Zielknoten gekennzeichneten Kontrollzustand eingenommen. Hinzu kann nebender Ausfuhrung der Anweisung S das Eintreten weiterer Ereignisse kommen (siehespater). Betrachten wir ein Zustandsubergangsdiagramm wie in Abb. 2.5 gegeben,dann konnen wir die

”Kontrollzustande“ nonempty und empty als Pradikate auf den

Zustanden definieren:

Stack empty ≡ empty(s)

Stack nonempty ≡ ¬empty(s)

k′k

{Q} a {R}

Abb. 2.6.: Markierter Zustandsubergang von Knoten k zum knoten k′

Nicht notwendigerweise sind die Mengen der Zustande der Programmvariablen zuunterschiedlichen Kontrollzustanden disjunkt. In diesem Fall sind die Kontrollzustandenicht eindeutig durch Zustande der Programmvariablen charakterisiert. Will mandies erreichen, dann werden spezielle weitere Attribute (in der Regel genau ein Attri-but zur Abspeicherung des Kontrollzustandes) eingefuhrt, die den Kontrollzustandfesthalten. Ein Beispiel dafur ist der Befehlszahler in Prozessoren.

Um Kontrollzustande in dieser Weise eindeutig zu machen, gibt es prinzipiell zweiMoglichkeiten. Fur ein Zustandsubergangsdiagramm mit den Kontrollzustandenk1, . . . , kn konnen wir

� eine Variable pc (”position control“,

”program counter“) einfuhren mit der

Sorte

{k1, . . . , kn}

18. Marz 2014 35


� wir fuhren die Kontrollattribute k1, . . . , kn als Boolesche Attribute in den Zu-standsraum ein mit der Annahme (Invariante), dass stets genau einer dieserAttribute gultig ist:

(1) ki ⇒ ∀ j, 1 ≤ j ≤ n, i 6= j : ¬kj

(2) ∃ j, 1 ≤ j ≤ n : kj

Dies druckt aus, dass in einem sequentiellen ZUD stets genau ein Kontrollzustandgultig ist.

Sind die Menge der Zustande des Ubergangsdiagramms in den Kontrollzustandenpaarweise disjunkt, so konnen wir in einfacher Weise ein Zustandsubergangsdia-gramm in ein logisches Regelsystem zur Definition einer Zustandsmaschine uberfuhren.

Eine weitere Moglichkeit der Darstellung von Zustandsmaschinen durch Program-me sind verschrankt rekursive Prozeduren (in repetitiver Rekursion), indem wir ei-ne Prozedur fur jeden Kontrollzustand vorsehen. Dies entspricht der Technik zumSchreiben von Scannern und Parsern im Ubersetzerbau auf Basis von Automaten.

Die bisher betrachteten Automaten sind sequentiell. Die Ubergange werden se-quentiell (hintereinander) ausgefuhrt. Spater werden wir parallele Automaten be-handeln, in denen mehrere Zustande gleichzeitig gultig sind und gewisse Transitio-nen gleichzeitig ausgefuhrt werden.

2.2.3. Zustandsubergangssysteme als anweisungsorientierteProgramme

Jedes Zustandsubergangsdiagramm, bei dem die Zustandsubergange mit Anweisun-gen markiert sind, kann schematisch in ein anweisungsorientiertes Programm uber-setzt werden. Wir zeigen, wie dies schematisch erfolgen kann. Wir setzen das Pro-gramm dargestellt durch Dijkstras Guarded Commands voraus.

Sei V eine Menge von sortierten (getypten) Identifikatoren (Programmvariablen,Attributen) und die Menge der Zustande gegeben durch (sei M das Universum derDatenwerte) die folgende Menge von Belegungen der Identifikatoren

Σ = {V→ M}

Gegeben sei eine Zustandsmaschine uber dem Zustandsraum durch ein ZUD.

Um das ZUD in ein Programm zu ubersetzen, fuhren wir eine zusatzliche Variable pc(fur Program Counter) ein. Jede Kante der in Abb. 2.7 beschriebenen Form mit demWachter C und der Anweisung S wird in den Rahmen einer großen Widerholungs-anweisung (vgl. Befehlszyklus bei Rechenmaschinen) ubersetzt, der dem Ablauf der

36 18. Marz 2014


k

{C} S

i

Abb. 2.7.: Zustandsubergang

Zustandsmaschine (iteriertes Ausfuhren von Zustandsubergangen) entspricht:

do

. . .

[] pc = k ∧ C then S; pc := i

. . .

od

Dadurch erhalten wir schematisch ein Programm fur eine gegebene Zustandsmaschi-ne. Nach diesem Schema konnen wir aus einem Zustandsdiagramm Code

”generie-

ren“.

2.2.4. Anweisungsorientierte Programme alsZustandsubergangssysteme

Jedes anweisungsorientierte Programm kann umgekehrt schematisch in ein Zustands-ubergangssystem umgeschrieben werden, indem wir uber die Menge der Belegungenseiner Programmvariablen einen Zustandsraum definieren. Zusatzlich benotigen wireinen abstrakten Befehlszahler. Dazu wird jede der Anweisungen mit einer Markeaus dem Kontrollzustand eindeutig markiert.

Wir demonstrieren dies fur bewachte Anweisungen. Zuerst fuhren wir eine Men-ge M von Marken ein und reichern dann das Programm mit paarweise verschiedenen(”eindeutigen“) Marken an, so dass vor jede Anweisung (ob einfach oder zusammen-

gesetzt) und am Ende jeder Anweisungen genau eine Marke eingefugt wird. Zusam-mengesetzte Anweisungen enthalten ebenfalls eine Marke zur Markierung und im In-neren weitere Marken fur jede Unteranweisung. Auch das Ende des Programms wirddurch eine Marke gekennzeichnet. Die Marken kennzeichen die Kontrollzustande desProgramms eindeutig. Die so durch Marken angereicherten Programme brechen wirschrittweise durch folgende Regeln in einzelne Aktionen auf.

Wir beginnen mit der sequentiellen Komposition: Jedes Programm entspricht einerAnweisungsfolge sequentielle

Komposition

m1 : S1; . . . ; mn : Sn; mn+1

18. Marz 2014 37


und wird dann zu der Anweisung (mit i = 1, ..., n) umgeformt

pc := m1;

do

. . .

[] pc = mi then Si; pc := mi+1

. . .

od

Nun brechen wir innerhalb dieser Wiederholungsanweisung zusammengesetzte An-Wieder-holungs-anweisung

weisungen S in bewachten Teilanweisungen der Form

[] G ∧ pc = m0 then S; pc := m1

weiter auf (der Wachter pc = mi entspricht true ∧ pc = mi).Wir ersetzen dazu Sequenzen, die aus zwei Anweisungen bestehen:

[] G ∧ pc = m0 then m0 : S0; m1 : S1; pc := m2

durch zwei bewachte Anweisungen, die wir mit Hilfe des Befehlszahlers ansteuern:

[] G ∧ pc = m0 then m0 : S0; pc := m1

[] pc = m1 then m1 : S1; pc := m2

Wir ersetzen geschachtelte if–Anweisungen der Form

[] G ∧ pc = m then m : if . . . [] Gi then mi : Si [] . . . fi; pc := m′

durch Anweisungen

[] G1 ∧ G ∧ pc = m then m1 : S1; pc := m′

. . .

[] Gn ∧ G ∧ pc = m then mn : Sn; pc := m′

[] ¬G1 ∧ · · · ∧ ¬Gn ∧ G ∧ pc = m then abort; pc := error

Hier verwenden wir einen ausgewahlten Kontrollzustand error, den einen Fehlerzu-stand darstellt.

Die Anweisung

[] G ∧ pc = m then m′′ : do . . . [] Gi then mi : Si [] . . . od; pc := m′

wird durch das Programmstuck

[] G ∧ pc = m then m: nop; pc := m′′ Einstieg in do. . . od

38 18. Marz 2014


[] G1 ∧ pc = m′′ then m1 : S1; pc := m′′

. . .[] Gn ∧ pc = m′′ then mn : Sn; pc := m′′

Ausfuhrungder Wiederholung

[] ¬G1 ∧ . . . ∧ ¬Gn ∧ pc = m′′ then nop; pc := m′ Ausstieg aus do . . . od

ersetzt.Zusammengesetzte Anweisungen werden durch diese Regeln Schritt fur Schritt

aufgebrochen. Aus einem baumartig hierarchisch strukturierten Programm entstehteine einzige große do–Wiederholung, wobei diese Wiederholungsanweisung eine Zu-standsmaschine beschreibt. Man beachte, dass durch das Programm auch die Gra-nularitat der Zustandsmaschine (das Aufbrechen von Anweisungen in Teilschritte)festgelegt wird. Auf diese Weise entsteht aus einem Programm eine Menge von Ak-tionen, wobei jede Aktion aus einer Bereitschaftsbedingung (dem Wachter) und einerAnweisung besteht.

Der Ubergang zu einen Automaten ist nun trivial. Wir erhalten nach Abschlußder Umformung ein Programm der Form

if . . . [] Gk ∧ pc = ak then bk : Sk; pc = ck [] . . . fi

Dabei sind ak, bk und ck Marken aus einer endlichen Menge M von Marken und Skist eine Anweisung.

Wir konstruieren fur diesen Automaten ein ZUD wie folgt: Die Kontrollzustandesind gegeben durch die Elemente der Menge M. Fur jede bewachte Anweisung k inoben angegebener Form fuhren wir in den Graphen eine Kante von ak nach ck einmit der Markierung {Gk}Sk.

Beispiel 2.9: Aufbrechen eines Programms in ZustandsubergangsdiagrammDas Programm

do min < max then k := (min + max)/2;if a[k] ≤ x then min := k[] a[k] ≥ x then max := k fi

od

wird durch das Einfuhren von Marken angereichert. Dies fuhrt zu dem Programm

m0 : do min < max then m1 : k := (min + max)/2;m2 : if a[k] ≤ x then m3 : min := k

[] a[k] ≥ x then m4 : max := kfi

odm5 :

Wir erhalten durch die Anwendung unserer Umformungsregeln das Programm

18. Marz 2014 39


pc := m0;m0 : do min < max ∧ pc = m0 then nop; pc := m1

[] pc = m1 then k := (min + max)/2; pc := m2

[] a[k] ≤ x ∧ pc = m2 then min := k; pc := m0

[] a[k] ≥ x ∧ pc = m2 then max := k; pc := m0

[] ¬(min < max) ∧ pc = m0 then nop; pc := m5

odm5 :

und daraus schließlich den Automaten, der im Abb. 2.8 gegeben ist. 2

m0

{min < max}

m5

m2

m1

k := (min + max) / 2

{¬(min < max)}

{a[k] ≤ x}

min := k

{a[k] ≥ x}

max := k

Abb. 2.8.: Zustandsmaschine

Oft ist es dabei gunstig, große Anweisungsfolgen als eine Anweisung aufzufassen,wenn sie keine Ein/Ausgabeanweisungen oder Zugriffe auf gemeinsame Programm-variable enthalten und einen lokalen sequentiellen Kontrollfluss besitzen. Dies er-laubt uns ein System mit großeren, erheblich groberen Einzelschritten zu betrach-ten und erleichtert das Verstandnis fur Systemablaufe, weil die Kombinatorik einge-schrankt wird. Wichtig ist dabei fur parallel ablaufende Programme (siehe spater)die Granularitat des Aufbrechens des Programms in Einzelanweisungen. Wir bre-chen nur Anweisungen auf, die nicht als unteilbar gekennzeichnet sind.

Beispiel 2.9: Aufbrechen eines Programms (Fortsetzung)Wenn wir im Programm die Granularitat der Anweisungen andern, wirkt sich dasauf die Gultigkeit der Invarianten aus. Nehmen wir an, dass in einem Programm die

40 18. Marz 2014

2.3. Zustandsmaschinen mit Eingabe und Ausgabe

Invariante min ≤ k ≤ max gilt. Wenn wir statt k := (min+max)/2 zwei Anweisungen

k := (min + max);

k := k/2;

verwenden, gilt die Invariante min ≤ k ≤ max im Zustand zwischen diesen beidenAktionen nicht mehr. 2

Der entscheidende Unterschied zwischen einem Programm und einer Zustandsma-schine besteht darin, dass in dem Programm die Positionen im Programmtext vorjeder Anweisung einen impliziten Kontrollzustand beschreiben, wohingegen in Zu-standsmaschinen die Kontrollzustande explizit Teil des Zustandsraums sind.

2.3. Zustandsmaschinen mit Eingabe und Ausgabe

In diesem Abschnitt betrachten wir Zustandsmaschinen mit Ein- und Ausgabe. Ein-und Ausgabe stellen besondere Formen von Aktionen in vernetzten Systemen dar.

Definition: Zustandsmaschinen mit Ein-/Ausgabe ZM mitEin−/Ausgabe

Sei Σ eine Menge von Zustanden, s0 ∈ Σ ein Anfangszustand, I eine Menge vonEingabenachrichten und O eine Menge von Ausgabenachrichten. Eine nichtdetermi-nistische Zustandsmaschine (∆, s0) mit Eingaben aus Menge I und Ausgaben ausMenge O wird durch die Ubergangsfunktion

∆ : Σ × I→ ℘(Σ × O)

beschrieben. 2

Dabei gibt es zwei Varianten von Automaten mit Ein-/Ausgabe: Bei Mealy-Automatenhangt die Ausgabe sowohl von der aktuellen Eingabe und dem Zustand ab, beimMoore-Automaten hangt die Ausgabe nur vom aktuellen Zustand ab. Dann gilt furalle Zustande σ und σ′ sowie alle Eingaben i1 und i2:

{e1 | ∃σ′ ∈ Σ : (σ′, e1) ∈ ∆(σ, i1)} = {e2 | ∃σ′ : (σ′, e2) ∈ ∆(σ, i2)}

Die Eingabe beeinflusst hier nur die Festlegung des Nachfolgezustands. Moore-Automaten sind somit ein Spezialfall der Mealy-Automaten.

Zustandsmaschinen mit Ein-/Ausgabe haben eine starke Ahnlichkeit zu Zustands-ubergangssystemen mit Aktionen, bei denen wir nur jeweils Ein- oder Ausgabeaktio-nen betrachten (vgl. I/O-Automata in [LSVW96]). Allerdings ist hier fur ein einfa-ches Kompositionskonzept durch Nebenbedingungen sicherzustellen, dass in jedemZustand jede Eingabe stets moglich ist.

Zustandsubergange von Zustandsmaschinen mit Eingabe i ∈ I und Ausgabe o ∈O sowie Anfangszustand σ ∈ State und Nachfolgezustand σ′ ∈ State entsprechen derAussage

(σ′, o) ∈ ∆(σ, i)

18. Marz 2014 41


Wir schreiben fur diese Aussage auch

σi/o−→ σ′

Auch Zustandsmaschinen mit Ein/Ausgabe lassen sich durch Zustandsubergangs-diagramme beschreiben. Allgemein stellen wir diese Zustandsubergangsdiagrammewie in Abb. 2.9 gezeigt dar. Wir verwenden eine spezielle Schreibweise, um auszu-drucken, dass im Kontrollzustand k der Ubergang moglich ist: Falls die ZusicherungQ im aktuellen Zustand gilt und die Eingabe i ∈ I verfugbar ist, dann wird der Uber-gang in den Kontrollzustand k′ ausgefuhrt, wobei die Ausgabe o ∈ O erfolgt und derNachfolgezustand σ′ durch die Zusicherung R uber Zustand σ und σ′ charakterisiertist.

Ist Q aquivalent zu true, so lassen wir den Wachter {Q} einfach weg. Beispiele furZustandsubergangsdiagramme finden sich in Abb. 2.10 und 2.11.

k

{Q} i / o {R}

k'

Abb. 2.9.: Markierter Zustandsubergang in ZUD fur ZM mit Ein-/Ausgabe

Beispiel 2.10: Eine Warteschlange als Zustandsmaschine mit Ein- und Aus-gabeWir definieren die Menge der Eingaben- und Ausgabewerte durch Sorten. Wirwahlen die folgende Festlegung fur die Sorten der Eingabe- und Ausgabedaten (dasElement R© bedeute hier

”Request“):

Sort Input = Data ∪ { R©}Sort Output = Data ∪ { R©}x: Eingabekanal

y: Ausgabekanal

Damit definieren wir folgende Mengen von Eingabe- und Ausgabeaktionen:

I = {(x : d) : d ∈ Input}O = {(y : d) : d ∈ Output}

Hier ist jede Aktion durch ein Paar bestehend aus einem Kanalnamen (in unseremFall x bzw. y) und einem Datenwert oder einem Signal dargestellt. Abb. 2.10 gibtdie Zustandsmaschine in Form eines Zustandsubergangsdiagrams an. 2

42 18. Marz 2014

2.4. Darstellungen von Zustandsmaschinen

NonemptyEmpty

x: d / – {q' = q ○ ‹d›}

x: ® / y: ® {q' = ‹ ›}

{q = ‹d›} x: ® / y: d {q' = ‹ ›}

{q = ‹d› ○ q' Λ q' ≠ ‹ ›} x: ® / y: d

x: d / – {q' = q ○ ‹d›}

Abb. 2.10.: Eine Warteschlange als Zustandsmaschine mit Ein- und Ausgabe

Wir kommen auf dieses Konzept einer Zustandsmaschine mit Ein- und Ausgabeunter dem Stichwort Schnittstellenbeschreibung und stromverarbeitende Funktionwieder zuruck. Wir zeigen insbesondere, dass wir jede Zustandsmaschine auf einestromverarbeitende Funktion abbilden konnen und umgekehrt.

Fasst man in den oben eingefuhrten Automaten Eingabe und Ausgabe zu jeweilseiner Aktion zusammen, dann erhalten wir wieder mit Aktionen markierte Automa-ten. Allerdings geht damit die Betonung der unterschiedlichen Rollen von Ein- undAusgabe verloren.


Um eine Zustandsmaschine darzustellen, stehen uns folgende Moglichkeiten zurVerfugung:

� mathematische Angabe der Ubergangsfunktion,

� Charakterisierung der Ubergangsfunktion mit logischen Mitteln,

� Darstellung durch programmiersprachische Notation,

� graphische Darstellung durch Ubergangsdiagramm,

� tabellarische Darstellung und

� Darstellung als Matrix.

Wir stellen einige dieser Moglichkeiten im weiteren einander gegenuber. Wir be-handeln die Beschreibungsmoglichkeiten nur fur Zustandsmaschinen mit Ein- undAusgabe. Die Darstellungsformen lassen sich auf die anderen Arten von Zustands-maschinen ubertragen.

18. Marz 2014 43


2.4.1. Analytische Darstellung

Eine Zustandsmaschine ist unmittelbar durch die Angabe der Ubergangsfunktionund Anfangszustande festgelegt. Die Zustandsmaschine definieren wir dann durchanalytische

Darstellung ein Quintupel:

A = (I,O,Σ,∆, s0),

wobei die Bestandteile wie folgt definiert sind:

I – eine Menge von Eingabenachrichten,O – eine Menge von Ausgabenachrichten,Σ – eine Menge von Zustanden,s0 ∈ Σ ein Anfangszustand,∆ – die Ubergangsfunktion, ∆ : Σ × I→ ℘(Σ × O).

Zur Spezifikation von ∆ verwenden wir die klassische Notation der Mathematik,Logik und Mengenlehre. Wir erlautern das an einem einfachen Beispiel.

Beispiel 2.11: SpeicherzelleEine Speicherzelle, die einen Wert der Sorte Data speichert, kann durch eine Zu-standsmaschine wie folgt beschrieben worden:

I = {set(d) : d ∈ Data} ∪ {read, empty}O = {return(d) : d ∈ Data} ∪ {done, rejected}Σ = Data ∪ {void}∆(void, set(d)) = {(d,done)}∆(d, read) = {(d, return(d))}∆(d, empty) = {(void,done)}∆(d, set(d′)) = {(d, rejected)}∆(void, read) = {(void, rejected)}∆(void, empty) = {(void,done)}σ0 = void

Diese Maschine erlaubt kein Uberschreiben eines gespeicherten Werts. Dieser musszunachst geloscht werden, bevor er erneut gesetzt wird. 2

Manchmal benutzen wir statt einer Ubergangsfunktion

∆ : Σ × I→ ℘(Σ × O)

zwei Funktionen:

∆P : Σ × I→ ℘(Σ) und ∆V : Σ × I→ ℘(O).

44 18. Marz 2014


Allerdings ist bei dieser Reprasentation im Falle des Nichtdeterminismus die Kop-pelung der nichtdeterministischen Auswahl fur Folgezustand und Ausgabe nichtmoglich. Im Falle vom Moore-Automaten konnen wir in der zweiten Funktion dieEingabe weglassen.

Im Prinzip konnen alle Arten von Zustandsmaschinen mit Ein- und Ausgabe mitmathematischen Mitteln beschreiben werden. Allerdings werden solche Beschreibun-gen schnell umfangreich und ubersichtlich.

2.4.2. Graphische Darstellung

Graphisch wird eine Zustandsmaschine direkt mit der Hilfe von Zustandsubergangs-diagrammen dargestellt. Diese Moglichkeit haben wir bereits ausfuhrlich betrachtet. graphische

DarstellungDeswegen gehen wir gleich zur tabellarischen und Matrix-Darstellung weiter. Wirgeben lediglich unser Beispiel Speicherzelle graphisch in Abb. 2.11 an. Der in Abb.2.11 beschriebene Automat ist total und deterministisch.

Die Ubersetzung des Diagramms in die mathematische Notation ist rein schema-tisch moglich.

Voll

v ≠ void

Leer

v = void

set(d) / done {v = d}

empty / done {v = void}

read / rejected {v = void} empty / done {v = void}

read / return(v)

set(b) / rejected

Abb. 2.11.: Zustandsubergangsdiagramm fur Speicherzelle

2.4.3. Tabellarische Darstellung

Diese Darstellung ist unterschiedlich fur Mealy- und Moore-Zustandsmaschinen. Fur tabellarischeDarstellungden Mealy-Automaten brauchen wir zwei Tabellen: Ubergangstabelle und Ausgabe-

tabelle, in beiden Tabellen sind die Zeilen Eingabewerte und die Spalten Zustande.Fur den Moore-Automaten brauchen wir nur eine Tabelle - eine gekennzeichnete Mealy/Moore-

AutomatUbergangstabelle.

a) Fur den Mealy-AutomatenIn der Ubergangstabelle schreiben wir in der Kreuzungsstelle von Zeile i undSpalte j den Zustand σk, in den der Automat ausgehend von dem Zustand σj

18. Marz 2014 45


durch die Aktion (Eingabe) xi ubergeht.In der Ausgabetabelle schreiben wir in der Kreuzungsstelle von Zeile i undSpalte j die Ausgabe yk, den der Automat ausgibt, wenn er von dem Zustandσj durch die Aktion (Eingabe) xi ubergeht.

Beispiel 2.12: Automat A1 (Deterministischer Mealy-Automat)Folgende zwei Tabellen beschreiben einen Automaten:

Ubergangstabelle Ausgabetabelle

σ0 σ1 σ2

x1 σ2 σ0 σ0

x2 σ0 σ2 σ1

σ0 σ1 σ2

x1 y1 y1 y2

x2 y1 y2 y1

Das entsprechende Ubergangsdiagramm ist in der Abb. 2.12 angegeben. 2

σ0

x2 / y1

σ2σ1

x1 / y1

x1 / y2

x2 / y1

x1 / y1

x2 / y2

Abb. 2.12.: Mealy-Automat

b) Fur den Moore-AutomatenIn der gekennzeichneten Ubergangstabelle schreiben wir in der Kreuzungsstellevon Zeile i und Spalte j den Zustand σk, in den der Automat von dem Zustandσj durch die Eingabe xi ubergeht. Die Spalte j ist in diesem Fall nicht nur mitdem Zustand σj, sondern auch mit der Ausgabe yl gekennzeichnet.

Beispiel 2.13: Automat A2 (Deterministischer Moore-Automat)

Gekennzeichnete Ubergangstabelle

σ0/y1 σ1/y1 σ2/y3 σ3/y2 σ4/y3

x1 σ1 σ4 σ4 σ2 σ2

x2 σ3 σ1 σ1 σ0 σ0

46 18. Marz 2014


Das entsprechende Ubergangsdiagramm ist in der Abb. 2.13 angegeben. 2

σ0

σ2

σ1

y1

σ4

σ3

y3

y2

y3

y1

x1

x1

x1

x2x1

x2

x2

x2

x2

x1

Abb. 2.13.: Moore-Automat

Noch ubersichtlichere Darstellungen erhalten wir beim Einsatz von Tabellen, wennwir logische Formeln tabellarisch darstellen (vgl. [Par92]).

Beispiel 2.14: Logikbasierte Tabelle fur SpeicherzelleFur die Speicherzelle konnen wir fur die Formel

∆(σ,a) = {(σ′,b)}

die folgende Tabelle angeben:

σ a σ′ b

void read void rejectedvoid set(d) d donevoid / d empty void doned read d return(d)d set(d′) d rejected

Hier gibt es oft Moglichkeiten, durch geschickte Wahl der durch die Tabelle darge-stellte Formel eine sehr kompakte, ubersichtliche Darstellung zu bekommen.

18. Marz 2014 47


2.4.4. Matrix–Darstellung

Nun beschreiben wir die Matrix–Darstellung fur Zustandsmaschinen mit Ein- undAusgabe.Matrix-

Darstellung

a) Fur den Mealy-AutomatenMatrix n× n (quadratisch), n = |Σ|. Jede Zeile und jede Spalte in der Matrixsind gekenzeichnet durch Zustande.In der Kreuzstelle von Zeile i und Spalte j schreiben wir ein Paar xi/yj: DerAutomat geht im Zustand σi durch die Aktion (Eingabe) xi in den Zustandσj uber und erzeugt die Ausgabe yj. Wenn es keinen Ubergang von σi nach σjgibt, steht an dieser Kreuzungsstelle der Eintrag

”–“.

Die Matrix fur den Automaten A1 (Abb. 2.12) ist in der Abb. 2.14 gegeben:

σ0 σ1 σ2

σ0 x2/y1 − x1/y1

σ1 x1/y1 − x2/y2

σ2 x1/y2 x2/y1 −

Abb. 2.14.: Matrix fur den Mealy-Automaten

b) Fur Moore-AutomatenMatrix: n× n und Vektor n× 1.Jede Zeile und jede Spalte in der Matrix sind gekennzeichnet durch Zustande.In der Kreuzungsstelle von Zeile i und Spalte j steht xij: Der Automat gehtim Zustand Si durch die Aktion (Eingabe) xi in den Zustand σj uber. Wennes keinen Ubergang von σi zum σj gibt, steht an dieser Kreuzungsstelle derEintrag

”–“.

Jedes Element yi im Vektor (in der Zeile i) korrespondiert zum Ausgang, denim Zustand σi rausgeben wird.

Die Matrix mit dem Vektor fur den Automaten A2 (Abb. 2.13) ist in der Abb. 2.15angegeben:

σ0 σ1 σ2 σ3 σ4

σ0 − x1 − x2 − y1

σ1 − x2 − − x1 y1

σ2 − x2 − − x1 y3

σ3 x2 − x1 − − y2

σ4 x2 − x1 − − y3

Abb. 2.15.: Matrix fur den Moore-Automaten

48 18. Marz 2014


Beispiel 2.15: BahnubergangGegeben sei ein beschrankter Bahnubergang. Das System besteht aus einem Signal,einem Sensor und einem Schrankenpaar. Das Signal bestimmt, ob ein Zug in denkritischen Abschnitt einfahren darf. Der Sensor erkennt, ob sich ein Zug in diesemkritischen Abschnitt befindet. Das Schrankenpaar kann den Bahnubergang fur denStraßenverkehr sperren.

Die Komponenten des Systems konnen folgende Zustande annehmen:

Signal 0 1Rot Grun

Schranke 0 1geschlossen geoffnet

Sensor 0 1Abschnitt frei Zug im Abschnitt

Um das System als Zustandsmaschine zu modellieren, wir geben die Tabelle derZustande, sowie deren mogliche Folgezustande an:

18. Marz 2014 49


Signal Schranke Sensor Signal Schranke Sensor0 0 0 0 1 0

1 0 00 1 0 0 0 01 0 0 1 0 1

0 0 01 0 1 1 0 0

0 0 10 0 1 0 0 0

0 1 1 0 1 11 1 0 1 1 01 1 1 1 1 1

2

2.5. Klassen und Objekte als Zustandsmaschinen

Auch Objekte bzw. Klassen der objektorientierten Programmierung konnen in ih-rem Verhalten als Zustandsmaschinen aufgefasst und modelliert werden. Objektewerden in der Objektorientierung durch Klassen beschrieben. Ihre Zustande werdendurch die Belegungen ihrer Variablen (

”Attribute“) gekennzeichnet, die Eingaben

entsprechen – wenn wir die Ausfuhrung von Methodenaufrufen als atomare Aktio-nen auffassen – Methodenaufrufen und die Ausgaben den Ruckgabewerten fur dieMethodenaufrufe. Wir fassen Methodenaufrufe und Ruckgabewerte als Nachrichtenauf:

sort Call = methcall(name : MethodId,par : Parameters)

sort Return = callreturn(name : MethodId,par : Parameters, ret : ReturnValues)

Die Objektidentifikatoren lassen wir in dieser Modellbildung der Einfachheit halberweg. Die Zustande eines Objekts entsprechen der Verbundsorte (Record-Sorte):

sort ObjectState = state(att1 : AttSort1, . . .)

Damit erhalten wir folgende Ubergangsfunktion:

∆ : ObjectState× Call→ ObjectState× Return

die das Verhalten des Objekts als Zustandsmaschine mit Eingabe und Ausgabe be-schreibt.

50 18. Marz 2014


Beispiel 2.16: Lesen und Schreiben eines AttributsWir betrachten die folgende Klassendefinition:

class Container ={ attribute

a: var M;methods

write = (x: M): a := x;read = (y: var M): y := a

}

Die Objekte der Klasse Container entsprechen Zustandsmaschinen mit dem Zu-standsraum

Σ = { m : m Element der Sorte M}

und den folgenden Ubergangen (wobei m ∈ Σ den Zustand darstellt)

mmethodcall(write,x)/callreturn(write,ε)

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ x

mmethodcall(read,y)/callreturn(read,m)

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ m

Jeder Methodenaufruf entspricht somit einem Zustandsubergang mit Ein- und Aus-gabe. 2

Bei dieser Modellierung setzen wir voraus, dass ein Methodenaufruf nicht auf Un-teraufrufe (

”forwarded calls“) fuhrt, sondern unmittelbar zu einer Ruckantwort. An-

dernfalls mussen die Zustande aller Objekte, die uber Unteraufrufe verandert wer-den, mit in den Objektzustand und seine Anderung einbezogen werden, oder dieUnteraufrufe mussen in Nachrichten verwandelt werden. Wir erweitern dazu dieSorte Call und Return um entsprechende Attribute:

sort Call = methcall (oid: ObjectId,name: MethodId,par: Parameters )

sort Return = callreturn (oid: ObjectId,name: MethodId,par: Parametersret : ReturnValues )

sort Message = Call | Return

18. Marz 2014 51


Damit erhalten wir folgende verallgemeinerte Ubergangsfunktion:

∆ : ObjectState× Message→ ObjectState× Message

Diese Zustandsmaschine beschreibt die Reaktionen des Objekts in Hinblick auf Me-thodenaufrufe. Diese Reaktionen bestehen neben einem Zustandsubergang in derAusgabe der Ruckkehrnachricht oder in der Ausgabe eines Untermethodenaufrufs.In Folge werden auch Reaktionen des Objekts auf Ruckkehrnachrichten als Zu-standsubergange betrachtet.

Beispiel 2.17: Geldautomat objektorientiertSei Betrag eine Sorte, die den Geldbetrag definiert (im einfachen Fall konnen wirNat als Betrag nehmen).

class Bancomat{ methods

// Die Karte k wird eingefugt, wenn diese akzeptabel ist, wird accept true gesetzt,// sonst false;

insertcard = (k: Karte, accepted: var Bool): Karte

// Die Geheimzahl p wird eingegeben,// wenn diese akzeptabel ist, wird accepted auf true gesetzt, sonst false;

open = (p: Pin, accepted: var Bool)

// Der Betrag b wird vom Konto abgzogen und bar ausgegeben, wenn dies das Limit// der Karte nicht uberschreitet, dann wird r auf true gesetzt, sonst auf false;

give money = (b: Betrag, r: var Bool)

// Die Karte k wird zuruckgegeben

close = (k: var Karte)

// Das Limit der Karte k wird uberpruft,// wenn es nicht uberschritten und akzeptabel ist, wird lim auf true gesetzt,// sonst auf false

limit = (k: Karte, lim: var Bool)}

Nun geben wir einen Automaten fur die Definition der Schnittstelle in Abb. 2.16 an.Dabei verwenden wir zwei Hilfsfunktionen:

52 18. Marz 2014


Kontostand: var Karte → Betragap: Karte → Pin

Dieser Automat beschreibt das Schnittstellenverhalten fur den Geldautomaten. 2

Das Beispiel macht deutlich, wie eng Objekte und Klassen mit Zustandsautomatenverwandt sind.

Betrachten wir jetzt ein Beispiel, das das Verhalten des Kontos beschreibt – dieskann man als Verfeinerung des Verhaltens im Zustand Pin ok verstehen.

Beispiel 2.18: Bankkonto objektorientiertWir betrachten die Klassen Konto und Konto Manager. Das Verhalten der Methodedagegen konnen wir durch Vor- und Nachbedingungen im Sinne eines Kontraktsspezifizieren:

class Konto{ attribute stand: var Betrag;// Der Betrag b wird vom Konto abgenommen// wenn dieser das Limit der Karte nicht uberschreitet,// wird done auf true gesetzt, sonst auf false;

method change (b: Betrag, done: var Bool)pre truepost (stand = stand′ < b ∧ done′ = false)

∨ (stand ≥ b ∧ stand′ = stand− b ∧ done′ = true)}

class Konto Manager{

// Uberweisung von Konto a nach Konto c, den Betrag b,// wenn die Transaktion erfolgreich war, wird done true, sonst false.

method trans = (b: Betrag, a,c: Konto, done: var Bool). . .}

Die Zustandsautomaten, die dem Konto-Objekt k und Konto-Manager m entspre-chen, sind in der Abb. 2.17 und 2.18 dargestellt.

Man beachte: methcall(change,c,-b,d) bedeutet, dass der Betrag b zum Kontoc hinzugefugt wird. Der Schnittstellenautomat ist sehr ahnlich zu der Spezifikationmit Vor- und Nachbedingungen (vgl.

”Design-by-Contract“). 2

Durch die Darstellung durch Zustandsmaschinen wird der interaktive Charakter derObjekte unterstrichen.

18. Marz 2014 53


Idle

methodcall(insertcard, card) / accepted {k = card}

Pin_ok

Card

{ methodcall(limit, k, b) = true} – / b, true

methodcall(close) / k

Pin

{accepted = true}methodcall(open, pin) / accepted

{accepted = false}methodcall(open, pin) / accepted

{accepted = true}methodcall(give_money, m) / –{b = m}

{ methodcall(limit, k, b) = false} – / 0, false

methodcall(close) / k

Abb. 2.16.: Schnittstellenautomat fur Geldautomaten

•

WartetUU

methcall (change, k, b, done) / callreturn(change, k, b, done′){ (stand′ = stand < b ∧ ¬done′)∨ (0 ≤ stand′ = stand− b ∧ done′) }

Abb. 2.17.: Schnittstellenautomat fur Klasse Konto

2.6. Nebenlaufigkeit und Parallelitat

Die bisher betrachteten Zustandsmaschinen sind durchweg sequentiell. Sie fuhrenZustandsubergang um Zustandsubergang nacheinander aus. Um Nebenlaufigkeit,das heißt, das zeitliche nebeneinander oder parallele Ausfuhren von Zustandsubergangenauf einem gemeinsamen Zustandsraum zu modellieren, gibt es folgende prinzipielleKonstruktionen.

Seien die Zustandsmaschinen (∆1, α1) mit Zustandsraum Σ1 und (∆2, α2) mitZustandsraum Σ2 gegeben. Wir definieren eine Zustandsmaschine (∆, α) mit einemZustandsraum Σ, der das Produkt der Zustandsraume der gegebenen Maschine ist:

Σ = Σ1 × Σ2

Wir erhalten den Anfangszustand

α = (α1, α2)

54 18. Marz 2014


Warten

methcall(trans, m, b, a, c, d) / methcall(change, a, b, d)

Prüfung

Überweisung

{d = false } callreturn(change, a, b, d) / callreturn(trans, m, b, a, c, d) {d = false }

callreturn(change, c, -b, d) / callreturn(trans, m, b, a, c, d) {d = true }

{d = true }callreturn(change, a, b, d) / methcall(change, c, -b, d)

Abb. 2.18.: Schnittstellenautomat fur Klasse Konto Manager

Fur die Zustandsubergangsfunktion

∆ : Σ→ ℘(Σ)

haben wir die folgenden Optionen.Beim Interleaving (asynchroner Nebenlaufigkeit,

”oder“-Parallelitat) der beiden

Maschinen wird nur jeweils ein Schritt einer der beiden Maschinen ausgefuhrt: Interleaving(asynchroneNebenlaufig-keit,“oder“-Parallelitat)

∆(σ1, σ2) = {(τ1, τ2) : (τ1 ∈ ∆1(σ1) ∧ τ2 = σ2)∨ (τ2 ∈ ∆2(σ2) ∧ τ1 = σ1) }

Die Auswahl, fur welche der Maschinen ein Schritt gewahlt wird, erfolgt nichtde-terministisch. Ein besonderer Fall vom Interleaving ist Stuttering, bei dem es auch Stuttering

moglich ist, dass keine der beiden Maschinen einen Schritt macht:

∆(σ1, σ2) = {(τ1, τ2) : (τ1 ∈ ∆1(σ1) ∧ τ2 = σ2)∨ (τ2 ∈ ∆2(σ2) ∧ τ1 = σ1) }∨ (τ1 = σ1 ∧ τ2 = σ2)

Bei synchroner Nebenlaufigkeit (”

und“-Parallelitat) werden jeweils zwei Schritte der synchroneNebenlaufig-keit(”

und“-Parallelitat)

gegebenen Maschinen gleichzeitig in einem Schritt der zusammengesetzten Maschinedurchgefuhrt:

∆(σ1, σ2) = {(τ1, τ2) : τ1 ∈ ∆1(σ1) ∧ τ2 ∈ ∆2(σ2)}

Es sind naturlich auch Mischungen der beiden Konzepte der nebenlaufigen Kompo-sition moglich, wobei einige der Schritte synchron und andere im Interleavingmodusausgefuhrt werden.

18. Marz 2014 55


∆(σ1, σ2) = {(τ1, τ2) : (τ1 ∈ ∆1(σ1) ∧ τ2 = σ2)∨ (τ2 ∈ ∆2(σ2) ∧ τ1 = σ1)∨ (τ1 ∈ ∆1(σ1) ∧ τ2 = ∆(σ2)) }

Wir konnen aus den gegeben Zustandsmaschinen auch eine Zustandsmaschine mitdem Zustandsraum

Σ = Σ1 ∪ Σ2

konstruieren (wir nehmen an: Σ1 ∩ Σ2 = ∅) und wahlen einen Anfangszustand

α = α1 oder α = α2

Fur die Ubergangsfunktion

∆ : Σ→ ℘(Σ)

definieren wir

∆(σ) =

{∆1(σ) ∪ Ξ1(σ) falls σ ∈ Σ1

∆2(σ) ∪ Ξ2(σ) falls σ ∈ Σ2

Dabei sind

Ξ1 : Σ1 → ℘(Σ2)

Ξ2 : Σ2 → ℘(Σ1)

zusatzliche Ubergangsfunktionen, die die Ubergange zwischen den Zustandraumenbeschreiben. Auf diese Weise erhalten wir eine zusammengesetzte Zustandsmaschi-ne die stets entweder in einem Zustand der Maschine 1 oder in einem Zustandder Maschine 2 ist. Wir sprechen auch von der disjunkten Vereinigung oder derSumme der Zustandsmaschinen und auch von einer

”oder“-Zusammensetzung der

Zustandsraume.Nebenlaufige zusammengesetzte Zustandsmaschinen finden sich in den Statecharts

(vgl. [Har87]) und in Folge der Aufnahme von Statecharts in den Formalismus auchin UML (vgl. [BD00]). Dabei werden die Zustandsraume zusammengesetzter Maschi-nen aus den Zustandsraumen gegebener Maschinen durch Produktbildung und Ver-einigung zusammengesetzt. Insbesondere werden or - und and -Zusammensetzungenverwendet. and -Zusammensetzungen werden durch gestrichelte Linien ausgedruckt.Sie entsprechen dem Produkt von Zustandsmaschinen, genauer der Zustandsraume.or -Zusammensetzungen werden durch durchgezogene Linien ausgedruckt. Sie ent-sprechen der Summe von Zustandsmaschinen genauer der Vereinigung der (disjunk-ten) Zustandsraume.

Beispiel 2.19: Summe und Produkt von ZM zur Modellierung einer Fern-steuerung (Fernseher)

56 18. Marz 2014


TV

Fernsehapparat Fernbedienung

Abb. 2.19.: TV-System bestehend aus Fernsehapparat mit Fernsteuerung

Die Abb. 2.19 stellt ein TV-System mit Fernsteuerung als Zustandsdiagramm (alsBeispiel fur einen and -Zustand) dar. Das TV-System gliedert sich in den Fernseh-apparat und die Fernbedienung. Den entsprechen zwei Automaten, aus denen dasTV-System nebenlaufig zusammengesetzt ist.

Fernsehapparat

Ein

Ton

Bild

Kanäle

ein

aus Aus

Abb. 2.20.: Fernsehapparat als strukturierter Zustandsautomat

Das Zustandsdiagramm in Abb. 2.20 beschreibt den Fernsehapparat. Der Automatist entweder im Zustand Aus oder im Zustand Ein. Der Zustand Ein untergliedert sichin drei Unterzustande bzw. Zustandsautomaten, die parallel laufen und die Zustandefur Ton, Bild und Kanal modellieren.

Die auftretenden Teilzustande entsprechen den in Abb. 2.21, 2.22 und 2.23 an-gegebenen Automaten. In ahnlicher Weise laßt sich die Fernbedingung modellieren.Dann gibt es eine Kommunikation von der Fernbedienung zum Fernsehapparat. Dar-auf kommen wir unter dem Stichwort Interaktion zuruck. 2

In den Beispielen haben wir nur die Komposition von Zustandsmaschinen betrach-tet, die auf disjunkten Zustandsraumen arbeiten. Man kann aber auch Zustands-maschinen nebenlaufig komponieren, die uberlappende Zustande besitzen. Im Fal-le der asynchronen Nebenlaufigkeit ist das nicht weiter schwierig. Bei synchro-

18. Marz 2014 57


Bild

Farbe

0col_down H

1…

col_up

col_down

9

col_up

Helligkeit

0br_down H

1

…

br_up

br_down

9

br_up

Abb. 2.21.: Bild

nen Ubergangen konnen aber Konflikte auftreten, wenn parallel durchgefuhrte Zu-standsubergange gemeinsame Attribute unterschiedlich besetzen wollen.

Gewisse Zustandsubergange nebenlaufiger Maschinen konnen zueinander im Kon-flikt sein, wenn sie auf dem gleichen Zustandsraum arbeiten und von einem Zustandunterschiedliche, sich gegenseitig ausschließende, sich widersprechende Zustande er-zeugen. Das heißt, dass solche Ubergange nicht sinnvoll zeitlich nebeneinander syn-chron ausgefuhrt werden konnen. Dies erfordert eine Koordination und Synchroni-sation der Ausfuhrung der Zustandsubergange. Wir besprechen diese Problematikim folgenden Abschnitt im Detail.

2.7. Parallele Programme mit gemeinsamen Variablen

Eine besondere Form der nebenlaufigen Zustandsubergangssystemen bilden parallelablaufende Programme, die auf gemeinsamen Variablen und damit auf nicht disjunk-ten Zustandsraumen arbeiten. Eine gemeinsame Variable (engl.

”shared variable“)gemeinsame

Variable(sharedvariable)

ist ein Zustandsattribut, auf das von unterschiedlichen, zeitlich parallel ablaufendenProgrammen lesend und zumindest von einem der Programme schreibend zuge-griffen wird. Gemeinsame Variable dienen der Koordination, Synchronisation undallgemeiner der Kommunikation zwischen parallel ablaufenden Programmen undZustandsmaschinen.

58 18. Marz 2014


Ton

Lautstärke

0ton_down H

1…

ton_up

ton_down

9

ton_up

Lautsprecher

Ein

Aus

ton_on

ton_off

Fernsteuerung

Ein

Tonwahl

Bildwahl

Kanalwahl

Aus

ein

aus

Abb. 2.22.: Ton und Fernsteuerung

2.7.1. Gemeinsame Variable

Anders als oben im Fall des Produktzustandsraums fur nebenlaufige Zustands-maschinen enthalten nebenlaufige Zustandsmaschinen mit gemeinsamen Variablenuberlappende Zustandsanteile. Seien die Zustandsmaschinen mit Ubergangsfunktio-nen

∆1 mit Zustandsraum Σ1 = {V1 → M}

und

∆2 mit Zustandsraum Σ2 = {V2 → M}

gegeben. Sei V = V1 ∪ V2. Die Menge V0 = V1 ∩ V2 der gemeinsamen Variablen seidabei nicht notwendigerweise leer. Die Zustandsraume konnen sich also uberlappen.

18. Marz 2014 59


Tonwahl

ton_down

ton_up

Ton

Bildwahl

col_down

col_up

Bild

Kanalwahl

chan_down

chan_up

Kanal

Abb. 2.23.: Automaten fur Ton- und Kanalwahl

V0 bezeichnet die Menge der gemeinsamen Programmvariablen.gemeinsameProgramm-variable

Wir definieren eine Zustandsmaschine ∆ mit Zustandsraum

Σ = {V→ M}

und mit der Ubergangsfunktion ∆ = ∆1‖∆2, wobei

∆ : Σ→ ℘(Σ)

durch Interleaving (asynchroner Nebenlaufigkeit) der beiden Maschinen. Es wird ineinem Schritt der zusammengesetzten Maschine jeweils nur ein Schritt einer derbeiden Maschinen ausgefuhrt:

∆(σ) = {τ : (τ |V1 ∈ ∆1(σ|V1) ∧ τ |(V\V1) = σ|(V\V1))

∨ (τ |V2 ∈ ∆2(σ|V2) ∧ τ1|(V\V2) = σ|(V\V2)) }

Hier bezeichnet σ|V1 die Einschrankung der Abbildung σ auf die Elemente aus V1.Beachte, dass σ : V1 ∪ V2 → M, σ|V1 : V1 → M und σ|V2 : V2 → M.

Die Operation ∆1 ‖ ∆2 nennen wir auch die parallele Komposition der Zustands-maschinen ∆1 und ∆2. Man beachte, dass im Fall gemeinsamer Variable im Allge-parallele

Komposition meinen synchrone Nebenlaufigkeit nicht mehr sinnvoll definiert werden kann, da diegleiche Variable in einem Schritt nicht konsistent in unterschiedlicher Form geandertwerden kann.

Bei gemeinsamen Variablen hangt die Menge der erreichbaren Zustande der entste-henden Zustandsmaschine entscheidend von der Granularitat der Transitionsschritteder gegebenen Zustandsmaschinen ab. Unter Granularitat verstehen wir dabei dasMaß, in wie viele Teilschritte ein umfangreicher Zustandsubergang zerlegt ist. Spal-ten wir einen Zustandsubergang etwa in der Maschine ∆1 in zwei Ubergange mitZwischenzustand auf, so entstehen durch das Interleaving von ∆1 mit ∆2 ganz neueAblaufe, da nun die Maschine ∆2 in dem Zwischenzustand moglicherweise Ubergange

60 18. Marz 2014


ausfuhren kann und damit unter Umstanden ganz andere Zustande als vorher er-reicht werden konnen.

Beispiel 2.20: Granularitat der parallelen Komposition mit gemeinsamen Va-riablenWir betrachten folgende Automaten:

Σ = N

mit

∆i : Σ→ ℘(Σ) fur i := 1, 2, 3

definiert durch

∆1(n) =

{0 falls n ungerade

n+ 2 falls n gerade

∆2(n) = {n+ 2}

∆3(n) = {n+ 1}

Die Maschinen ∆2 und ∆3 zahlen beide den Zustand hoch, nur in unterschiedlichenSchritten. Sei σ = 2 der Anfangszustand.

Fur ∆1 gelten die Invarianten σ ≥ 2 und”σ gerade“.

Fur ∆2 gelten die Invarianten σ ≥ 2 und”σ gerade“.

Fur ∆3 gilt die Invariante σ ≥ 2.Fur ∆1‖∆2 gelten die Invarianten σ ≥ 2 und

”σ gerade“.

Fur ∆1‖∆3 gelten beide Invarianten nicht.2

Das einfache Beispiel zeigt, wie sensibel das Verhalten einer zusammengesetzten Zu-standsmaschine von der Granularitat und der Verschrankung (engl.

”Interleaving“)

der Zustandsubergange abhangt.

Achtung: Bei der parallelen Komposition von Zustandsmaschinen brauchenwir den gleichen Anfangszustand fur die gemeinsamen Variablen.

Die Anfangszustande definieren wir wie folgt

σ0 = {σ : σ|V1 ∈ σ10 ∧ σ|V2 ∈ σ2

0 }

σ0 ist leer, falls die Maschinen sich nicht auf Anfangszustande fur die gemeinsamenVariablen verstandigen konnen.

18. Marz 2014 61


Beispiel 2.21: Anfangszustand bei gemeinsamen VariablenDie Zustandsmaschinen M1 und M2 (vgl. Abb. 2.24) konnen nicht durch paralleleKomposition zusammengesetzt werden, weil die Zustandsmaschine M1 am Anfangden Zustand n = 0 hat und die Zustandsmaschine M2 den Wert n = 1. Um dieparallele Komposition auf diesen Zustandsmaschinen durchzufuhren, mussen wirden Anfangszustand der gemeinsamen Variable n fur eine der Maschinen andern.

Wir definieren eine neue Zustandsmaschine M2′ durch Hinzufugen eines neuenZustands zur Maschine M2 und bekommen folgende Mengen von erreichbaren Va-riablenzustanden der Maschinen M1, M2 und M2′:

R∆1 = {0, 2, 4, . . .} = {k | even(k)}R∆2 = {1, 3, 5, . . .} = {k | odd(k)}R∆′2

= {0, 1, 3, 5, . . .} = {0} ∪ {k | odd(k)} = {0} ∪ R∆2

Die Zustandsmaschinen sind in Abb. 2.24 durch Zustandsubergangsdiagramme dar-gestellt. Unter der Fairness-Annahme (die besagt, dass jede der Maschinen nach ei-ner Reihe der Schritte der anderen Maschine immer wieder einen Zustandsubergangdurchfuhrt) gilt, dass der Zustand Alarm (n = 1) der Maschine M1‖ M2′ erreichbarist, obwohl fur die Maschine M1 dieser Zustand unerreichbar war. 2

Even

M1:

Alarm

n := 0

{odd(n)} n := 1

{even(n)} n := n + 2

Odd

M2:

n := 1

{odd(n)} n := n + 2

Add

M2':

Odd

n := 0

n := n + 1{odd(n)} n := n + 2

Abb. 2.24.: Zustandsmaschinen mit gemeinsamer Variable

Das Beispiel zeigt erneut, wie dramatisch sich die Menge der erreichbaren Zustandeund damit das Verhalten des Systems bei der parallelen Komposition mit gemein-samen Zustandsanteilen andert.

62 18. Marz 2014


2.7.2. Stabile Pradikate und Invarianten bei paralleler Komposition

Fur eine durch Interleaving aus zwei Zustandsmaschinen zusammengesetzte Zu-standsmaschine ∆ ist ein Pradikat, das fur beide Zustandsmaschinen stabil ist, eben-falls stabil. Damit konnen wir die Stabilitat eines Pradikats fur eine nebenlaufigeZustandsmaschine beweisen, indem wir seine Stabilitat fur beide Zustandsmaschinenzeigen. Dies liefert ein einfaches modulares Verfahren zum Beweis von Stabilitatsei-genschaften fur parallele Zustandsmaschinen.

Achtung: Die obige Aussage fur Stabilitat gilt nicht fur Invarianten. Ist dasPradikat P eine Invariante fur beide Zustandsmaschinen M1 und M2, so gilt nichtnotwendigerweise, dass P eine Invariante fur M1 ‖ M2 ist, da die Menge der

”gemein-

sam“ erreichbaren Zustande großer sein kann, als die Vereinigung der von jeder derMaschinen erreichbaren Mengen von Zustanden.

Beispiel 2.22: Stabilitat fur parallele ZustandsmaschinenIn obigem Beispiel sind σ > 2 und

”σ gerade“ stabile Zusicherungen der Maschinen

(∆1, 2) und (∆2, 2)

also auch stabil fur die Maschine

(∆1 ‖ ∆2, 2) 2

Man beachte, dass die Stabilitat von Zusicherungen kritisch von der Granularitat derZustandsubergange abhangt. Wir illustrieren diese Aussage in folgendem Beispiel.

Beispiel 2.23: GranularitatWir betrachten den Zustand: x: var Nat mit der Invariante even(x) spezifiziert durch

even(x)⇐⇒ x ∈ {0, 2, 4, 6, 8, 10, . . . }.

Die Zustandsubergangsdiagramme sind in der Abb. 2.25 gegeben.Die Maschine M1 fuhrt zwei Schritte der Maschine M2 in einem Schritt durch. Furdie Maschine M1 gilt die Invariante even(x), fur die zweite Maschine nicht. In beidenMaschinen wird nie ein Alarm ausgelost werden. Wir bekommen folgende Mengenvon erreichbaren Variablenzustanden:

R∆1 = {2, 4, 6, . . .}R∆2 = {2, 3, 4, 5, 6, 7, . . .}R∆3 = {2}

Komponiert man die Maschinen mit der Maschine M3 aus Abb. 2.26, so erhalt mandurch die Komposition mit der Maschine M2 moglicherweise einen Alarm (genauer,Alarm liegt in der Menge der erreichbaren Zustande), nicht aber fur die MaschineM1.

18. Marz 2014 63


Even

M1:

Alarm

x := 2

{odd(x)} x := 1

x := x + 2

Even

M2:

n := 2x := x + 1

Odd

Alarm{odd(x)} x := 0

x := x + 1

Abb. 2.25.: Zustandsubergangsdiagramme

S1

M3:

S2

x := 2{odd(x)} x := 2

Abb. 2.26.: Zustandsubergangsdiagramm fur Maschine M3

2

Achtung: Kennen wir nur die Menge der erreichbaren Zustande bei gegebe-nen Maschinen, so konnen wir uber die Menge der erreichbaren Zustande der durchparallele Komposition entstehenden Maschine in der Regel keine Aussagen machen(außer die Mengen sind identisch). Wir benotigen die Zustandsubergangsfunktionen,um uber die Menge der erreichbaren Zustande der Komposition Aussagen machenzu konnen. 2

Das Beispiel zeigt, wie sensibel die Granularitat und die Wahl der Zwischenzustandefur das Verhalten der zusammengesetzten Zustandsmaschine sind.

Beispiel 2.24: ZM, fur die Invariante I1 giltSei das Zustandsubergangsdiagramm in der Abb. 2.27 gegeben. Fur diese Zustands-maschine gilt die Invariante I1 = 0 ≤ s ≤ 2 sowie s = i + k. 2

64 18. Marz 2014


s = 0

i = 1

i = 0 Λ k = 0 Λ s = 0

i := 0, s := 0

k = 1

s = 2

i := 1, s := 1

k := 0, s := 0

{s = 0} k := 1, s := 1

i := 1, s := 2k := 1, s := 2

i := 0, s := 1k := 0, s := 1

Abb. 2.27.: Beispiel fur Zustandsubergangsdiagramm mit Invariante 0 ≤ s ≤ 2 ∧ s = i + k

Wir sehen, dass Invarianten hilfreiche Mittel zur Charakterisierung von Zustands-maschinen sind, aber fur Aussagen bei Komposition von Maschinen nicht ausreichen.Wir sagen auch, dass die Invarianteneigenschaft nicht kompositional ist.

2.7.3. Parallele Programme, unteilbare Aktionen, gegenseitigerAusschluß und Koordination

Uber gemeinsame Variablen konnen wir den Ablauf parallel zusammengesetzter Zu-standsmaschinen steuern und koordinieren. Ist fur eine der Zustandsmaschinen furbestimmte Belegungen der gemeinsamen Programmvariablen kein Zustandsuber-gang moglich, so konnen ausschließlich die anderen Zustandsmaschinen Zustands-ubergange ausfuhren, bis durch einen Ubergang ein Zustand hergestellt wird, in demdie eine Maschine wieder Ubergange ausfuhren kann (vgl. [Hoa76]).

Wie bereits erlautert, kommt es bei der parallelen Komposition von Zustandsma-schinen mit gemeinsamen Variablen stark auf die Granularitat der Zustandsubergangegenauer auf die auftretenden Zwischenzustande an. Beschreiben wir die parallel ab-laufenden Zustandsmaschinen durch Programme, so benotigen wir geeignete Mittel,um die Granularitat (

”Atomizitat der Anweisungen“) auszudrucken.

Seien S1, S2, . . . Anweisungen, etwa Guarded Commands. Fur eine zusammenge-setzte Anweisung, die darin besteht, dass Anweisungen S1 und S2 parallel ausgefuhrtwerden, schreiben wir:

dS1 ‖ S2c

18. Marz 2014 65


und allgemeiner

dS1 ‖ S2 ‖ S3 ‖ . . . ‖ Smc

Werden Anweisungen parallel ausgefuhrt, so ist fur die Festlegung ihrer Wirkungim Sinn der erreichten Zustande die Frage entscheidend, ob sie gemeinsame Variableenthalten. Andernfalls unterscheidet sich die synchrone Ausfuhrung im Ergebnis vonder Ausfuhrung im Interleavingmodus nicht.

Bei parallelen Programmen mit gemeinsamen Variablen bietet sich der Interlea-vingmodus an, da gewisse Anweisungen ohnehin nicht echt nebeneinander ausgefuhrtwerden konnen. Dabei ist die

”Granularitat“ der Ausfuhrung, wie bereits deutlich ge-

macht, entscheidend fur das Verhalten. Abhangig davon, in wieviele Teilschritte eineAnweisung aufgebrochen wird, konnen namlich die Teilanweisungen unterschiedlichmiteinander verzahnt ausgefuhrt, unterschiedliche Zwischenzustande auftreten, undsomit radikal unterschiedliche Resultate erzielt werden.

Definition: (Disjunkt) parallele Programme(disjunkt)paralleleProgramme

Zwei Programme heißen disjunkt, wenn keines der Programme Variablen verandert,auf die das andere Programm Lese- oder Schreibzugriff hat. Sei change(Si) die Men-ge aller Variablen in Si, die auf der linken Seite einer Anweisung stehen und var(Si)die Menge aller Variablen in Si. Formal gilt:

Die Programme S1, . . . , Sn heißen disjunkt parallel, wenn gilt

∀i, k ∈ {1, . . . , n} : change(Si) ∩ var(Sk) = ∅ fur i 6= k 2

Disjunkt parallele Programme beeinflussen sich gegenseitig nicht. Wir erhalten diefolgende einfache Beweisregel fur disjunkt parallele Programme:

{Q} S1; . . . ; Sn {R}{Q}dS1‖ . . . ‖Snc{R}

Sind Programme nicht disjunkt parallel, so ist die Festlegung des Verhaltens beiparalleler Komposition erheblich komplizierter. Insbesondere ist die Granularitatder Anweisungen fur das Interleaving entscheidend.

Um bei Anweisungen S, die mit gemeinsamen Variablen ausgefuhrt werden, sicher-zustellen, dass sie in einem Stuck – ohne Verzahnung mit anderer Anweisung parallelablaufende Programme – als

”unteilbare“ Aktion ausgefuhrt werden, verwenden wir

die Klammern 〈〉. Wir schreiben

〈S〉

um auszudrucken, dass bei Ausfuhrung dieser Anweisung in einem Kontext dazuparallel ablaufender Programme, die Anweisung S in einem Schritt –

”unteilbar“

66 18. Marz 2014


– als ein Zustandsubergang ausgefuhrt wird. Damit konnen wir die Granularitatkontrollieren.

Ein zweites wichtiges Element der Koordination paralleler Programme bestehtdarin, mit der Ausfuhrung darauf zu warten, dass eine bestimmte Bedingung eintritt.Wir schreiben in Erweiterung der Notation der bewachten Anweisungen wie folgt:

if . . . []〈Gi then Si〉; Ti [] . . . fi

um auszudrucken, dass der i-te Zweig der bedingten Anweisung nur gewahlt wird,wenn die Bedingung Gi wahr ist; dann wird, ohne dass die Ausfuhrung unterbrochenwird, Si als unteilbare Aktion und anschließend Ti ausgefuhrt. Dabei wird sicherge-stellt, dass parallel zur Auswertung des Wachters Gi und Ausfuhrung von Si keineandere Aktion dazwischen ausgefuhrt wird und somit Gi bei Beginn der Ausfuhrungvon Si sicher wahr ist. Sind alle Zweige gesperrt, so wird gewartet, bis Gi (oder einerder anderen Wachter) wahr wird. Erfolgt das nie, terminiert die Anweisung nicht.Die Notation verwenden wir analog auch fur Wiederholungsanweisungen.

Wir fordern im Folgenden weiter, dass in parallel ablaufenden Programmen ge-meinsame Variable nur im Innern unteilbarer Aktionen auftreten.

Beispiel 2.25: Dekkers AlgorithmusEs sind die Ablaufe zweier Prozesse zu koordinieren. Jeder Prozess durchlauft einekritische und eine unkritische Phase, so dass folgendes sicher gestellt werden soll:

� (1) beide Prozesse sind nie gleichzeitig in ihrer kritischen Phase;

� (2) beide Prozesse behindern sich nicht mehr als durch (1) notig.

Sei die Sorte der Identifikatoren der Prozesse ID = {A, B} und A = B sowie B = A.Wir arbeiten mit folgendem Programm, das – neben den Parametern – die globalegemeinsame Variable

v : var ID

benutzt.Fur das im Weiteren behandelte Beispiel verwenden wir eine Konstruktion, die

das Warten auf das Eintreten einer Bedingung ausdruckt. Wir schreiben

await 〈 B then S 〉 end

fur (sei b eine lokale Variable der Sorte Bool)

b := true;do 〈 B ∧ b then S 〉; b := false[] 〈 ¬B ∧ b then nop 〉od

18. Marz 2014 67


dadurch drucken wir”zyklisches“ Warten auf die Bedingung B aus.

proc dekker = (x, y : var Bool, p : ID):d Nichtkritische Phase von Prozess p;〈 x := true 〉;if 〈¬y then nop 〉 y = false[] 〈 y then nop 〉;

if 〈 v = p then nop 〉[] 〈 v 6= p then x := false 〉;

await 〈 v = p then x := true 〉 end;fi; {v = p}await 〈 ¬y then nop 〉 end {v = p ∧ ¬y}

y = true

fiKritische Phase p;〈 v := ¬p 〉;〈 x := false 〉

c

Hier dient die Variable x dazu, anzuzeigen, dass das Programm in seine kritischePhase eintritt. Die Variable p zeigt an, welcher Prozess im Konfliktfall den Vortritterhalt. Wir starten das Programm parallel zu einem anderen Programm durch (seidie Programmvariable v beliebig mit A oder B vorbesetzt) durch die Anweisung

ddekker(x, y, A) ‖ dekker(y, x, B)c

Das Zustandsubergangsdiagramm, das dem Programm entspricht, ist in der Abb.2.28 gegeben.

Das Beispiel zeigt die Verwendung kritischer Bereiche. Gilt x ∧ y, dann ist einerder beiden Prozesse im zweiten Zweig der ersten if-Anweisung. Diesen verlasst ererst, wenn v als Wert seinen Id hat und der andere Prozess sein Signal auf false ge-setzt hat. Damit ist sicher gestellt, dass der andere Prozess nicht in seiner kritischenPhase ist.

2

Solange wir nur Programme betrachten, die sequentiell, isoliert von der UmgebungAnweisungen ausfuhren, macht das Warten auf das Eintreten gewisser Bedingungenoder Ereignisse keinen Sinn. Laufen jedoch parallel zur Ausfuhrung eines Programmsandere Programme oder Vorgange in der Umgebung des Programms ab, so ist esnicht nur sinnvoll, sondern fur bestimmte Aufgabenstellungen unverzichtbar, dassauf bestimmte Ereignisse, wie etwa das Eintreten bestimmter Bedingungen, gewartetwird.

68 18. Marz 2014


ncs

trying

¬x V ¬y V (v = A V v = B)

x := true

checking

cs

waiting

{v}

{v = p} x := true{¬y}

{v = p}

{¬y}

v := ¬p; x := false

waiting_priority

{v ≠ p} x := false

Abb. 2.28.: Zustandsubergangsdiagramm fur den Dekker-Algorithmus – cs bezeichnet die kriti-sche Phase, ncs die nichtkritische Phase

Beispiel 2.26: SemaphorEin Semaphor ist eine gemeinsame Variable s: var Nat, auf die nur durch zwei Ope-rationen P und V zugegriffen wird. P(s) und V(s) sind Prozeduraufrufe. V steht fur

”Freigeben“ und ist einfach zu beschreiben:

proc V = (s: var Nat): 〈 s := s + 1 〉

Schwieriger ist P. P steht fur”Protect“, das Schutzen eines Bereiches. P(s) entspricht

dem Herunterzahlen des Semaphors s um eins, aber nur, falls s > 0 gilt; andernfallswird gewartet.

Man konnte auf die Idee kommen, den Rumpf der Prozedur P wie folgt zu formu-lieren:

if 〈 s > 0 then s := s− 1 〉 fi

Diese Anweisung druckt aber nicht aus, dass auf das Eintreten der Bedingung ge-wartet werden soll. Vielmehr wird dadurch ausgedruckt, dass die Auswertung derAnweisung nicht terminiert, falls die Bedingung s > 0 nicht gilt, und andernfalls sum eins verringert wird. In jedem Fall wird die Anweisung ausgefuhrt, ohne dasszwangslaufig ein Wartezustand auftritt, falls s > 0 nicht gilt.

Deshalb deklarieren wir P wie folgt:

18. Marz 2014 69


proc P = (s: var Nat):if 〈 s > 0 then s := s - 1 〉[] 〈 s = 0 then nop 〉; P(s) fi

Die Anweisung im Rumpf von P terminiert, falls die Bedingung s > 0 eintritt. So-lange s = 0 gilt, wird die Rekursion immer wieder durchlaufen (

”busy waiting“).busy waiting

Der Unterschied zur obigen Anweisung ist subtil. Naturlich terminiert auch mit derzweiten Festlegung P(s) nicht, falls s > 0 nicht eintritt. Setzen wir jedoch zusatz-lich voraus, dass parallel ablaufende Programme fair ausgefuhrt werden, das heißt,dass jedes Programm immer wieder in die Lage versetzt wird, eigene Anweisungenauszufuhren, dann wird sicher gestellt, dass s erhoht wird, falls ein Programm eineV-Operation auszufuhren versucht, und schließlich die Ausfuhrung der Schleife derP-Operation fortgesetzt wird und dann unter der Bedingung s > 0 der Wert von sum eins verringert und terminiert. 2

Das obige Beispiel zeigt, wie unter der Annahme einer fairen Ausfuhrung das Wartenauf das Eintreten einer Bedingung formuliert werden kann. Man beachte, dass imobigen Beispiel zu Semaphoren die Moglichkeit, unteilbare Aktionen zu formulieren,von grundsatzlicher Bedeutung ist.

Parallel ablaufende Programme mit gemeinsamen Variablen und unteilbaren Ak-tionen besitzen ein komplexes, oft schwer zu analysierendes Verhalten. WesentlicheEigenschaften, die es sicherzustellen gilt, sind Verklemmungsfreiheit und gegenseiti-ger Ausschluss beim Durchlaufen kritischer Phasen.

2.7.4. Zusicherungsbeweise fur parallele Programme, Geistervariable

Ein Zusicherungsbeweis fur ein anweisungsorientiertes Programm ist ein”annotier-

tes“ Programm, bei dem jede Anweisung mit einer Vorbedingung und Nachbedin-gung versehen ist, die korrekt im Sinne der Hoare-Logik sind. Die Behandlung derar-tiger anweisungsorientierter paralleler Programme mittels der Beweisungsmethodedurch Zusicherungen nach Hoare wurde von Susan Owicki und David Gries (vgl.[OG76]) eingefuhrt. Die Beweise werden ungleich komplizierter, da Wechselwirkun-gen durch den parallelen Zugriff auf gemeinsame Variablen zwischen den Program-men auftreten konnen. Wechselwirkungen zwischen den Programmen uber die ge-meisamen Variablen heißen Interferenzen.Interferenzen

Wir wenden uns nun Zusicherungsbeweisen fur parallele Programme zu. Die Re-geln fur Korrektheit der Zusicherungen fur unteilbare Aktionen sind dabei so, als obdie Klammern 〈〉 nicht im Programm stehen wurden. Zusicherungsbeweise konnenfur parallel ablaufende Programme auch problemlos gefuhrt werden, solange in denZusicherungen nicht auf gemeinsame Variable Bezug genommen wird. Bei gemein-samen Variablen ist jedoch zunachst nicht sichergestellt, dass nicht die parallel ab-laufenden Programme deren Wert andern, so dass Zusicherungen dadurch ungultigwerden.

70 18. Marz 2014


Definition: Interferenzfreier Zusicherungsbeweis interferenz-freierZusicherungs-beweis

Wir nennen zwei Zusicherungsbeweise {Q1} S1 {R1} und {Q2} S2 {R2} (wobei wirannehmen, dass die zusammengesetzten Anweisungen S1 und S2 alle Zusicherungenenthalten, die fur die Beweise der Zusicherungen erforderlich sind) interferenzfrei,wenn alle Zusicherungen (auch im Inneren von S1 und S2) in den annotierten Pro-grammen {Q1} S1 {R1} und {Q2} S2 {R2} nicht auf gemeinsame Variable Bezugnehmen.

Wir erhalten die folgende einfache Beweisregel:

{Q1} S1 {R1}, {Q2} S2 {R2} beide Beweise interferenzfrei

{Q1 ∧ Q2} d S1 ‖ S2 c {R1 ∧ R2}

Treten in den Zusicherungen gemeinsame Variable auf, so konnen die Beweise furdie einzelnen Programme nicht ohne weiteres in den Kontext paralleler Programmeubernommen werden.

Der Begriff der Interferenzfreiheit von Beweisen lasst sich allerdings verallgemei-nern.

Definition: Interferenzfreiheit annotierter Anweisungen Interferenz-freiheitannotierterAnweisungen

Seien {Q1} S1 {R1} und {Q2} S2 {R2} annotierte Programme, bei denen alle Zuwei-sungen an gemeinsame Variable oder Abfragen gemeinsame Variable in unteilbarenAnweisungen vorgenommen werden. Die annotierte Anweisung {Q1} S1 {R1} ist inBezug auf {Q2} S2 {R2} interferenzfrei, wenn fur jede Zusicherung P in dem Beweis{Q1} S1 {R1} gilt: Fur jede Anweisung S, die Zuweisung außerhalb einer unteilbarenAktion oder eine unteilbare Aktion in S2 ist mit Vorbedingung {B}, gilt:

{B ∧ P} S {P}

Dies heißt, dass durch die Ausfuhrung von Anweisungen im Programm S2 keine derZusicherungen im Programm S1 ungultig werden konnen. 2

Damit konnen auch Beweise uber parallel ablaufende Programme mit gemeinsamenVariablen gefuhrt werden. Setzen wir zwei Programme mit Zusicherungsbeweisenzusammen, die wechselseitig interferenzfrei sind, so bleiben die Beweise gultig. Al-lerdings reicht diese Regel allein im Allgemeinen nicht aus, um die fur ein Programmgultigen Nachbedingungen auch zu beweisen.

Beispiel 2.27: Unvollstandigkeit des BeweiskalkulsDer Nachweis der Korrektheit des offensichtlich korrekt annotierten folgenden Pro-gramms

{x = a}d〈x := x + 1〉; 〈x := x + 1〉‖〈x := x + 1〉c{x = a + 3}

18. Marz 2014 71


ist mit obiger Regel fur sich nicht moglich. Die obige Regel ist nicht anwendbar, dadie fur den Beweis erforderlichen Zusicherungen die Voraussetzungen, dass sie nichtauf gemeinsame Variable Bezug nehmen, nicht erfullen. 2

Allerdings konnen wir im Kontext parallel ablaufender Programme wieder mit In-varianten arbeiten. Treten in einem Programm P alle gemeinsamen Variablen nur inunteilbaren Aktionen auf und ist eine Zusicherung J fur jede unteilbare AnweisungS und alle ubrigen Anweisungen S im Programm eine Invariante, d.h. gilt stets

{J} S {J}

so schreiben wir:

P inv J

Es gelten die Regeln

P inv J{J} P {J}

S1 inv J, S2 inv J{J} d S1 ‖ S2 c {J}

Ist {Q} S {R} ein Zusicherungsbeweis und gilt fur jedes Tripel mit Zuweisung S′, dienicht im Inneren einer unteilbaren Aktion steht, und jede unteilbarer Aktion S′

{Q′} S′ {R′}

in diesem Beweis auch

{Q′ ∧ J} S′ {J}

so gilt auch

{Q′ ∧ J} S′ {R ∧ J}

Mit Hilfe von Invarianten konnen wir Beweise uber Zusicherungen mit gemeinsamenVariablen fuhren.

Allerdings benotigen wir dafur in vielen Fallen zur Formulierung der Invarian-ten zusatzlich sogenannte Geistervariable (siehe [OG76]) und Geisteranweisungen.Geistervariable, auch Hilfsvariable genannt, dienen der Annotation eines Programmsdurch zusatzliche Variable und zusatzliche Anweisungen, so dass dabei aber der ur-sprungliche Programmablauf erhalten bleibt (vgl. auch Slicing in [AH90, Tip95,Ste99]). Durch die zusatzliche Annotation und die zusatzliche ProgrammvariableGeister-

variableHilfsvariable

konnen Kontrollzustande markiert werden und uber Hilfsvariablen Zusicherungsbe-weise und Invarianten formuliert werden, die sonst nicht moglich waren.

72 18. Marz 2014


Beispiel 2.27: Unvollstandigkeit des Beweiskalkuls (Fortsetzung)Wir annotieren das Programm mit den Hilfsvariablen h und k:

{x = a}h := k := 0;

d〈x := x + 1; h := 1〉; 〈x := x + 1; h := 2〉‖〈x := x + 1; k := 1〉c{x = a + 3 ∧ h = 2 ∧ k = 1}

Wir beweisen unschwer:

{h = 0}〈x := x + 1; h := 1〉; 〈x := x + 1; h := 2〉{h = 2}{k = 0}〈x := x + 1; k := 1〉{k = 1}

Wir nutzen ferner als Invariante: x = a+h+k. Die Invariante beweist sich unschwer.Die Kombination der beiden Beweismethoden liefert die gewunschte Aussage. Am

Ende des Programms gilt die Invariante x = a + h + k und ferner h = 2 und k = 1und damit x = a + 3. 2

Wir konnen generell Programme mit geeigneten Hilfsvariablen und Anweisungendafur anreichern, ohne ihr ursprungliches Verhalten zu andern.

Definition: Anreicherung eines Programms um Hilfsvariable (Geistervariable)und Geisteranweisungen, Slicing Slice

SlicingSei S ein Programm, eine zusammengesetzte Anweisung. S′ nennen wir ein um Hilfs-variable angereichertes Programm, wenn die Anweisung S′ aus S entsteht, indemwir einige zusatzliche Programmvariable (genannt Geistervariable) einfuhren, undZuweisungen an genau diese Geistervariable hinzufugen. Dabei wird vorausgesetzt,dass die rechten Seiten dieser Zuweisungen keine undefinierten Ausdrucke enthalten.S heißt auch Slice von S′. 2

Jeder Zusicherungsbeweis {Q} S′ {R} uber ein Programm S′, das durch Anreicherungaus dem Programm S mit Geistervariablen und Geisteranweisungen entsteht, beidem die Zusicherungen Q und R auf Geistervariable nicht Bezug nehmen, ist auchein Beweis fur {Q} S {R}. Wir erhalten die Regel:

{Q}S′{R}{Q}S{R}

S′ ist eine Anreicherung von S um Geistervariablen;

Q und R frei von Geistervariablen

Um Beweise zu kombinieren, verwenden wir die folgende Regel:

{Q1} S {R1}, {Q2} S {R2}{Q1 ∧ Q2} S {R1 ∧ R2}

Dadurch konnen wir Beweise mit Interferenzfreiheit mit Invariantenbeweisen kom-binieren. Dies liefert eine (relativ zur Logik der verwendeten Datenstrukturen) voll-standige Beweismethode (vgl. [OG76]). Relativ vollstandig heißt im Wesentlichen

18. Marz 2014 73


folgendes: Setzen wir voraus, dass wir ein vollstandiges Beweissystem fur die Re-chenstrukturen besitzen, auf denen die Programme arbeiten, so konnen wir jedeszutreffende Paar von Zusicherungen auch beweisen.

Wir geben ein Beispiel fur die Beweisfuhrung.

Beispiel 2.28: Parallele Suche in einem FeldWir betrachten die parallele Suche nach einen String in einem Feld. In einem Feldder Lange n≥1 sollen m≥1 parallele Prozeduren eine Zeichenkette s finden, fur dieencode(s) gilt.

Gemeinsame Variablen:a: Array[1 . . . n] Stringi: var Nat = 1j: var Nat = 0

Lokale Variablen (ik ist lokal fur Prozess k (k ∈ N ∧ 1 ≤ k ≤ m)):i1,. . . ,im: var Nat = 0,. . . ,0

Prozess k (k ∈ N ∧ 1 ≤ k ≤ m):proc pk :=

A: do ik < n ∧ j = 0 thenB: 〈 ik, i := i, i+1 〉;C: if ik≤n ∧ encode(a[ik]) thenD: j := ik;

fiod

E:

Wir wollen zeigen, dass wenn alle Prozesse terminiert haben und j=0, dann enthalt akeine passende Zeichenkette. Ist aber nach der Terminierung j>0, so soll encode(a[j])gelten.

Zur Vereinfachung des Korrektheitsbeweises nehmen wir an, dass die Ubergangezwischen jedem Paar benachbarter Kontrollflusspunkte A→B, A→E, B→C, C→D,C→A, D→A im Kontrollflussgraphen eines jeden Prozesses atomar sind.Sei pck die logische Variable fur den Kontrollflusszahler des Prozesses k (k ∈ N ∧1 ≤ k ≤ m). Die folgende Formel INV =∀ k∈N∩[1,m] :

ik< i ∧

pck ∈ {A,B}∨ (pck=C ∧ 0< ik)∨ (pck=D ∧ 0< ik≤n ∧ encode(a[ik]))∨ (pck=E ∧ (ik≥n ∨ j>0))

∧(0< j≤n ∧ encode(a[j]))∨j = 0∧(∀ l∈N∩[1,n] : ((l< i ∧ encode(a[l]))⇒ ∃ k∈N∩[1,m] : (l= ik ∧ pck∈{C,D})))

74 18. Marz 2014

2.8. Historische Bemerkungen zur Zustandssicht auf verteilte Systeme

denotiert eine stabile Invariante. INV ∧ (∀ k ∈ N∩ [1,m] : pck = E) impliziert dieNachbedingung

(j=0 ∧ (∀ l∈N∩[1,m] : ¬encode(a[l]))) ∨ (1≤ j≤n ∧ encode(a[j])) . 2

Das Beispiel zeigt erneut die kombinatorische Komplexitat paralleler Programme.Durch die zahllosen Abhangikeiten sind parallel ausgefuhrte Programme extremschwer zu verstehen, zu spezifizieren und zu verifizieren.

2.8. Historische Bemerkungen zur Zustandssicht auf verteilte

Systeme

Die Idee der Zustandsmaschine als Modell fur ein System zu verwenden ist so altwie die Informatik. Sehr fruh wurden Zustandsmaschinen fur die unterschiedlichs-ten Zwecke eingesetzt. So konnen Rechner stets als Zustandsmaschinen beschrie-ben werden. Auch Turingmaschinen sind eine Variante von Zustandsmaschinen, diedie Grundlage fur theoretische Uberlegungen zur Berechenbarkeit und Komplexitatvon Problemen legen. Ferner finden sich fruh endliche Automaten und Zustandsma-schinen – die in der theoretischen Informatik vornehmlich zur Definition formalerSprachen eingesetzt werden und auch im Compilerbau eine durchaus praktische Be-deutung haben.

Petri-Netze sind eine besondere Art von Zustandsmaschinen, bei denen die Ne-benlaufigkeit in der Struktur der Maschine explizit zum Ausdruck kommt. In den30 bis 40 Jahren des Entstehens der Informatik hat sich eine Vielzahl unterschiedli-cher Konzepte von Zustandsmaschinen herausgebildet, die fur die Modellierung vonSystemen mehr oder weniger gut geeignet sind.

Auch Betriebssysteme wurden oft als eine Menge von kooperierenden Zustands-maschinen dargestellt. Insgesamt ist die Idee, einen Rechner als Zustandsmaschinezu sehen und auch den Ausbau eines Rechners uber Betriebssysteme als eine Erwei-terung dieser Zustandsmaschine aufzufassen, schon in den 60er Jahren zu finden.

Die Idee der Zustandsmaschine mit einer Ausgabe oder markierten Ubergangenkommt erst in den 70er Jahren bedeutsamer zum Tragen, auch wenn die Ideenfur solche Maschinen deutlich weiter zuruckgehen, man denke nur an die Theorieder endlichen Automaten zur Beschreibung von Sprachen. Erst in den 70er und80er Jahren wird erkannt, dass die Idee der Zustandsmaschine unter Umstandengeeigneter fur die Behandlung von Nebenlaufigkeit ist, als programmiersprachlicheNotationen.

Eine Fulle von Arbeiten zu Zustandsubergangssystemen erschließt diesen The-menbereich. Besonders herauszuheben sind die Arbeiten um UNITY (vgl. [CM88]),bei denen vollig von Kontrollstrukturen von Programmen abstrahiert wird und Sys-teme als reine Zustandsubergangssysteme modelliert werden.

18. Marz 2014 75


Auf der gleichen Linie liegt der Ansatz von Leslie Lamport unter dem StichwortTLA (Temporal Logic of Actions, vgl. [Lam94]). Auch hier werden Systeme im We-sentlichen als Zustandsubergangsrelationen modelliert, wobei prinzipiell zwischenZustandsubergangen eines Systems und seiner Umgebung unterschieden wird. Aufdiese Weise wird TLA im Gegensatz zu UNITY sehr viel starker zu einem Ansatz zurBeschreibung verteilter Systeme. Die Idee einer Komponenten ist sehr viel deutlichersichtbar, TLA ist auch konsequent auf Modularitat ausgerichtet, was heißt, dass ausden logischen Eigenschaften von Teilsystemen auf die Eigenschaften eines Gesamt-systems vollstandig geschlossen werden kann. Dies trifft fur UNITY in Hinblick aufLebendigkeitseigenschaften nicht zu.

Großes Interesse hat fur die Behandlung von Zustandssystemen das Thema dertemporalen Logik gefunden. Temporale Logik (vgl. [vB91]) wird generell als die Logikder Zustandsubergangssysteme gesehen. Allerdings ist hierbei zu berucksichtigen,dass die Ausdrucksstarke der temporalen Logik eingeschrankt ist und dass umfang-reichere temporallogische Ausdrucke schnell unubersichtlich werden. Wir greifen dasspater auf.

Die Moglichkeiten des Model Checkings fur endliche Zustandsubergangssysteme,bei dem im Prinzip alle erreichbaren Zustande eines Systems uberpruft werdenum die Gultigkeit von Invarianten zu zeigen, haben auch das Interesse an Zu-standsubergangssystemen noch einmal verstarkt. Besonderes Interesse hat dabei dieAbstraktion von Zustandsubergangssystemen mit unendlichen Zustandsraumen aufZustandsubergangssysteme mit endlichen Zustandsraumen, auf denen dann ModelChecking-Untersuchungen durchgefuhrt werden konnen (vgl. [CGP99]).

Auch die grafische Darstellung von Zustandsubergangssystemen durch Zustands-ubergangsdiagramme hat eine lange Tradition in der Informatik. Allerdings standenzunachst so genannte Kontrollablaufdiagramme starker im Vordergrund, die sichnoch in der Spezifikationssprache SDL finden. Heute sind Zustandsubergangsdia-gramme starker vorherrschend. Dabei sind diese stark beeinflusst von den Ideen vonDavid Harel, die er unter dem Stichwort

”Statecharts“ publiziert hat (vgl. [Har87]).

Zugrunde liegt die Vorstellung, den Zustandsraum bereits grafisch strukturiert vor-zugeben und so die Zustandsubergangsdiagramme gleichzeitig zu nutzen, um dieStruktur der Zustandsraume darzustellen. Statecharts haben sich schnell durchge-setzt und sind insbesondere in Ansatzen wie ROOM + UML die vorherrschendeForm der Zustandsubergangsdiagramme.

76 18. Marz 2014

2.9. Ubungsaufgaben

2.9. Ubungsaufgaben

Ubungsaufgabe 2.1: Beschreiben Sie eine interaktive Warteschlange als Zu-standsautomaten und durch ein Zustandsubergangsdiagramm.

Ubungsaufgabe 2.2: Beschreiben Sie eine Fahrkartenautomat als Zustands-maschine.

Ubungsaufgabe 2.3: Schreiben Sie ein Programm, das aus zwei parallel ablau-fenden Teilprogrammen besteht, die gemeinsam parallel die Fakultat n! berechnen.

Ubungsaufgabe 2.4: Beschreiben Sie ein Flip-Flop als Zustandsmaschine mitEingabe und Ausgabe.

Ubungsaufgabe 2.5: Beweisen Sie die Korrektheit des Programmes aus derAufgabe 2 mit der Zusicherungsmethode.

Ubungsaufgabe 2.6: Mit welchem Zustand endet die Zustandsmaschine imBeispiel 2.2, wenn sie in einen Zustand (s, t) gestartet wird, wobei s und t beliebigeSequenzen seien?

18. Marz 2014 77


78 18. Marz 2014

3. Schnittstellensicht: FunktionaleBeschreibung von Systemkomponenten

In der Zustandssicht auf ein System haben wir im Vordergrund die Systemzustandeund die Zustandsubergange betrachtet. Das gibt uns gleichsam eine

”Innenansicht“

auf das System, wenn wir die Zustande als Teil einer internen Sicht einbezogen.Die Auswirkungen des Systems auf seine Umgebung und seine Interaktionen mitder Umgebung wird dabei nur als ein Aspekt betrachtet. Wenn wir ein System nut-zen oder es als Komponente in ein verteiltes System einbringen wollen, ist jedochfur uns weniger der

”interne“ Zustand oder Aufbau des Systems von Interesse, als

vielmehr seine Außenwirkung, etwa die Interaktionsmuster, die wir bei Nutzungdes Systems erwarten konnen. Dies bestimmt die Außenansicht, auch Schnittstel-lensicht genannt. Typischerweise beschreiben wir dann ein System, seine Nutzung Schnittstellen-

sichtund Wirkung, indem wir sein Zusammenwirken mit seiner Umgebung beschreiben.Im Vordergrund steht dabei, welche Informationen zwischen dem System und seinerUmgebung ausgetauscht werden und wie System und Umgebung zusammenwirken.Wir sprechen von der Schnittstelle des Systems. Oft wird dabei auch von den Datengesprochen, die zwischen dem System und seiner Umgebung uber die Systemgrenzefließen.

In diesem Kapitel behandeln wir die Schnittstellen- und Nutzungssicht auf einSystem, das mit seiner Umgebung interagiert und auf Ereignisse in seiner Umgebungreagiert. Wir sprechen von der Außensicht auf ein interaktives oder reaktives System.

3.1. Schnittstellenabstraktion

Ein System lauft in der Regel in einer Umgebung und interagiert mit dieser. Durchdie Systemgrenze wird ein klarer Schnitt zwischen System und Umgebung vorge-nommen. Alle relevanten Informationen uber das Zusammenwirken des Systems mitseiner Umgebung nennen wir seine Schnittstelle. Die Schnittstelle abstrahiert von Schnittstelle

allen internen Details eines Systems, die fur das Verstandnis des Zusammenwirkensdes Systems mit seiner Umgebung nicht von Bedeutung sind.

Es werden moglichst genau die Informationen in einer Schnittstellensicht doku-mentiert, die erforderlich sind um das Zusammenarbeiten des Systems mit geeignen-ten Systemumgebungen spezifizieren zu konnen. Da das Zusammenwirken eines Sys-tems T mit einer Umgebung U strenggenommen der Komposition der beiden SystemeT und U entspricht, ist es das Ziel der Schnittstellensicht, genau die Informationen

18. Marz 2014 79

Kapitel 3. Schnittstellensicht: Funktionale Beschreibung von Systemkomponenten

uber das Teilsystem (und gegebenenfalls auch Annahmen uber die Umgebung) zudokumentieren, dass das Verhalten des zusammengesetzten Systems (wieder im Sinnder Schnittstellensicht auf das zusammengesetzte System) daraus bestimmt werdenkann.

Den Ubergang von der internen Sicht zur Schnittstellensicht eines Systems nennenwir Schnittstellenabstraktion.

Wir demonstrieren die Schnittstellenabstraktion zunachst an einem einfachen Bei-spiel zweier Zustandsmaschinen mit unterschiedlichen Zustandsraumen aber glei-chem Schnittstellenverhalten in Hinblick auf ihre Ein/Ausgabe.

Beispiel 3.1: Zwei ZM mit Ein/Ausgabe mit unterschiedlicher Zustandsraumeaber mit gleichen SchnittstellenverhaltenIm Folgenden betrachten wir zwei Zustandsmaschinen mit Ein/Ausgabe. Wir wahlendie Ein/Ausgabe als Schnittstelle.1 Wir betrachten folgende zwei Zustandsraume:

Σ1 = Seq DataΣ2 = Set Data

und folgende Zustandsubergangsfunktionen

∆1: Σ1 × Input → ℘(Σ1 × Output)∆2: Σ2 × Input → ℘(Σ2 × Output)

wobei die Sorten Input und Output wie folgt definiert werden:

sort Input = in(x: Data) | getsort Output = out(x: Data) | empty

Wir definieren die Zustandsubergange wie folgt:

∆1(ε, get) = {(ε, empty)}∆1(〈d〉 ◦ s, get) = {(s, out(d))}∆1(s, in(d)) = {(s1

◦ 〈d〉 ◦ s2, empty): s1◦ s2 = s}

∆2(∅, get) = (∅, empty)∆2(m, get) = {(m \ {d}, out(d)): d ∈ m} ⇐ m 6= ∅∆2(m, in(d)) = {(m ∪ {d}, empty)}

In dieser Form sind beide Maschinen nicht Ein/Ausgabe-schnittstellenaquivalent.Die wiederholte Eingabe des gleichen Wortes fuhrt bei Maschine ∆1 zur wiederholtenAusgabe des Wortes, bei ∆2 jedoch nur zur einmalige Ausgabe.

1Man beachte: Fur Zustandsmaschinen konnen wir auch gemeinsame Programmvariable alsSchnittstelle wahlen. Das fuhrt auf einen anderen Schnittstellenbegriff und einen anderen Aqui-valenzbegriff.

80 18. Marz 2014

3.1. Schnittstellenabstraktion

Um das gleiche Verhalten zu bekommen, mussen wir die dritte Gleichung fur dieerste Maschine so wahlen, dass das Hinzufugen eines Elementes zur einen Sequenznach den gleichen Regeln wie das Hinzufugen eines Elementes zur einen Mengegewahrleistet ist:

∃ s1, s2 : s1◦ 〈d〉 ◦ s2 = s ⇒ ∆1(s, in(d)) = {(s, empty)}

¬(∃ s1, s2 : s1◦ 〈d〉 ◦ s2 = s)⇒ ∆1(s, in(d)) = {(s1

◦ 〈d〉 ◦ s2, empty): s1◦ s2 = s}

Ferner erlauben wir folgende Ubergange:

∆1(s, get) = {(s1◦ s2, out(d)): s = s1

◦ 〈d〉 ◦ s2}

Beide Maschinen zeigen jetzt das gleiche Ein/Ausgabeverhalten, wenn wir als An-fangszustande ε bzw. ∅ wahlen. Sie haben jedoch unterschiedliche Zustandsraumeund dementsprechend auch unterschiedliche Ubergangsfunktionen. 2

Dies liefert eine erste einfache Erkenntnis: Auch wenn Systeme dargestellt durch Zu-standsmaschinen unterschiedliche Zustandsraume haben, konnen sie doch das gleicheSchnittstellenverhalten aufweisen.

Uns interessieren in diesem Kapitel zwei Fragen:

� Was heißt es, dass zwei Systeme das gleiche Schnittstellenverhalten haben?

� Wie konnen wir eine Schnittstelle am besten festlegen, beschreiben und spezi-fizieren?

Die erste Frage ist abstrakt leicht zu beantworten.

Definition: Schnittstellenkompatibilitat zu einem System B Schnittstellen-kompatibilitatEin System A heißt zu einem System B schnittstellenkompatibel, wenn A in belie-

bigen Umgebungen durch B ersetzt werden kann, ohne, dass sich das aus Sicht derUmgebung und damit aus Schnittstellensicht das Verhalten andert. 2

Kompatibilitat erfordert zunachst syntaktische Kompatibilitat (siehe nachster Ab-schnitt); es mussen die syntaktischen Schnittstellen ubereinstimmen. Hinzu kommtdie Verhaltenskompatibilitat.

Schnittstellenkompatibilitat ist keine Aquivalenzrelation sondern eine partielleOrdnung. Fordern wir, dass A schnittstellenkompatibel zu B ist und umgekehrt,so sprechen wir von Schnittstellenaquivalenz.

Wir sind an einer expliziten Angabe der Information fur ein System interessiert,die die Schnittstellenkompatibilitat und -aquivalenz charakterisiert. Dazu fuhren wirein spezielles Modell fur Systeme ein.

18. Marz 2014 81


3.2. Syntaktische Schnittstellen: Kanale und gemeinsame

Variablen

Bei den Komponenten eines verteilten Systems ist es fur die Schnittstellensicht vonentscheidender Bedeutung, in welcher Weise die Komponenten in ihrem Verhaltenvon außen beeinflusst werden konnen und wie die Komponenten durch ihr Verhal-ten Einfluss nach außen ausuben konnen. Dazu mussen Informationen zwischen derKomponente und ihrer Umgebung ausgetauscht werden. Wir sprechen bei der Fest-legung, in welcher grundsatzlichen Form solch ein Informationsaustausch moglichist, von der syntaktischen Schnittstelle einer Systemkomponente.syntaktische

Schnittstelle Wir betrachten im Wesentlichen zwei Erscheinungsformen von Schnittstellen zwi-schen einem System und seiner Umgebung

�”gemeinsame“ Variable, gemeinsamer Speicher,

� Kanale fur Ein/Ausgabe (Nachrichtenaustausch).

Gemeinsame Variable sind Programmvariablen (Zustandsattribute) und somit Be-zeichnungen fur Teile des Zustands des Systems, die sowohl durch die Umgebungwie durch die Komponenten selbst geschrieben und/oder gelesen werden konnen.Wir erhalten Spezialfalle, falls gewisse gemeinsame Variable jeweils nur durch dieKomponenten oder aber nur durch ihre Umgebung gelesen oder geschrieben werdenkonnen. Dies fuhrt auf Systemstrukturen, bei denen ein Teil eines Systems auf eineVariable schreibt, wahrend ein anderer Teil des Systems darauf ausschließlich lesendzugreift.

Die Schnittstelle einer Komponente, die mit ihrer Umgebung uber gemeinsameVariable kommuniziert, wird also durch die Angabe der Variablen, deren Sorten undder Angabe der Schreib-/Lese-Rechte beschrieben.2 Lokale Variablen, also Variablenauf die eine Komponente exklusives Lese- und Schreibrecht besitzt, sind nicht Teilder Schnittstelle, da auf sie von außen nicht zugegriffen werden kann.

Kanale dienen zum Austausch von Nachrichten zwischen Komponenten oder zwi-schen einer Komponente und ihrer Umgebung. Ein Kanal entspricht einer Verbin-dung, uber die Nachrichten ausgetauscht werden. Fur den Nachrichtenaustausch gilt:Die syntaktische Schnittstelle beschreibt, welche Nachrichten ausgetauscht werdenkonnen. Ein Kanal ist gekennzeichnet durch einen Namen, den Kanalidentifikator,und eine Sorte, die Sorte der Nachrichten, die uber dem Kanal ausgetauscht werden.Hinzu konnen noch Angaben uber die spezifischen Regeln des Nachrichtenaustauschskommen. Kanale konnen letztlich auch als eine besondere Form gemeinsamer Varia-blen mit einer festgelegten Disziplin fur der Nachrichtenaustausch gesehen werden.

2Im Prinzip konnen wir auch synchrone Aktionen (auch Rendezvous oder Handshake genannt,siehe spater) zur Interaktion zwischen einem System und seiner Umgebung betrachten. Dieselassen sich jedoch auf die beiden genannten Konzepte abbilden.

82 18. Marz 2014

3.2. Syntaktische Schnittstellen: Kanale und gemeinsame Variablen

Wir beschranken uns im Weiteren auf gerichtete Kanale, uber die Nachrichtenstets in nur einer Richtung streng sequentiell ausgetauscht werden. Das bedeutet,dass die Nachrichten genau in der Reihenfolge, in der sie gesendet werden, emp-fangen werden. Bedeutsam ist dabei welche Pufferkapazitat ein Kanal besitzt. DiePufferkapazitat entspricht der maximalen Zahl von Nachrichten, die uber einen Ka-nal gesendet werden konnen, bevor die erste empfangen und aus dem Kanal entferntwird. Wir beschaftigen uns insbesondere mit zwei extremen Fallen, mit der Puffer-kapazitat 0 und ∞.

Ist die Pufferkapazitat 0, so kann keine Nachricht zwischengespeichert werden. Ei-ne Ubertragung erfordert demnach erst, dass neben dem Sender auch ein Empfangerbereit ist, die Nachricht sofort entgegenzunehmen. Wir sprechen von nachrichten-synchroner Kommunikation, in der Literatur auch Handshake-Kommunikation oderRendezvous genannt. Dabei ist es nahe liegend, mehrere Sender und Empfanger proKanal zuzulassen. Dabei nehmen wir an, dass ein bilateraler Nachrichtenaustauscherfolgt, wenn mindestens einer der Sender und mindestens einer der Empfanger zurKommunikation bereit ist. Dann erfolgt der Nachrichtenaustausch Punkt-zu-Punktzwischen diesem Sender und diesem Empfanger. Die ubrigen Sender und Empfangerbleiben davon unberuhrt. Sind mehrere Sender oder Empfanger gleichzeitig kommu-nikationsbereit, so wird nichtdeterministisch ein Paar ausgewahlt. nachrichten-

synchrone(Handshake-)Kommunikat-ionRendezvous

Ist die Pufferkapazitat eines Kanals ∞, so konnen Nachrichten immer gesendetwerden. Nach dem Senden kann der jeweilige Sender seine Aktivitaten ohne zu war-ten fortsetzen. Die Nachrichten werden an einen Empfanger ausgeliefert, sobald die-ser zum Empfang bereit ist. Tritt die Empfangsbereitschaft nie ein, so wird dieNachricht nie ausgeliefert.

Im einfachsten Fall existiert pro Kanal genau ein Sender und ein Empfanger. Dannwird durch den Nachrichtenaustausch keinerlei Nichtdeterminismus eingefuhrt. Wirkonnen auch viele Empfanger zulassen, die alle den gleichen Nachrichtenstrom er-halten. Wir sprechen dann von Broadcast-Ubertragung. Schließlich konnen wir auch Broadcast-

Ubertragungmehrere Sender auf einem Kanal zulassen. Dann werden die gesendeten Nachrich-ten zu einem sequentiellen Nachrichtenstrom gemischt. Das Mischen erfolgt dannnichtdeterministisch. Analoges gilt im Falle mehrerer Empfanger.

Im Prinzip konnen uber einen Kanal also mehrere Komponenten senden und emp-fangen. Wir beschranken uns zunachst jedoch auf den einfachen Fall, bei dem furjeden Kanal genau ein Sender und ein Empfanger existieren.

Kanale konnen auch als Spezialfall gemeinsamer Programmvariablen der SortePuffer verstanden werden. Umgekehrt konnen wir uber Komponenten mit Kanalenauch gemeinsame Programmvariablen nachbilden.

Wir konnen schließlich auch Komponenten betrachten, die sowohl mit Kanalen wieauch mit gemeinsamen Variablen arbeiten. Dann besteht die syntaktische Schnitt-stelle aus der Angabe der Kanale (genauer der Kanalnamen und Sorten) und dergemeinsamen Variablen.

18. Marz 2014 83


3.3. Strome und stromverarbeitende Funktionen

In diesem Abschnitt fuhren wir ein Modell fur Komponenten in interaktiven Sys-temen ein, die uber Datenstrome untereinander und mit ihrer Umgebung kommu-nizieren. Wir sprechen von asynchroner Kommunikation, da die Systeme, ohne aufdie Empfangsbereitschaft der Empfanger zu warten, Nachrichten austauschen.

3.3.1. Die Rechenstruktur der Strome

Eine besondere Rechenstruktur, die zur Modellierung sequentieller Systemablaufeund der Kommunikation auf Kanalen verwendet werden kann, sind Strome (auchDatenstrome genannt). Ein Nachrichtenstrom (Datenstrom, Ereignisstrom) dientStrom

zur Darstellung der Folge von Nachrichten (Daten, Ereignissen), die uber ein se-quentielles Kommunikationsmedium zur Nachrichtenubertragung geschickt werden.Da wir uber die Dauer der Nutzung des Mediums keine Einschrankungen machenwollen, betrachten wir im Grenzfall auch unendliche Strome.

Strome entsprechen endlichen und unendlichen Sequenzen von Datenelementenwie etwa Signalen, Nachrichten, Aktionen, Ereignisse oder auch Zustanden. Wirbetrachten im Weiteren zahlreiche Spielarten von Stromen wie Datenstrome, Si-gnalstrome, Ereignisstrome, Strome von Zustanden und auch Strome von Aktionenzur Darstellung sequentieller Aktionsstrukturen.

Fur eine gegebene Sorte α mit Tragermenge M definieren wir die polymorphe Sorte

sort Stream α

mit der Tragermenge (hier bezeichnet ⊥ das Symbol fur das Ergebnis einer nicht-terminierender Berechnung)

Mω = (M \ {⊥})∗ ∪ (M \ {⊥})∞

Hier steht 〈〉 nicht nur fur den leeren Strom (es gibt nichts zu ubertragen), son-dern reprasentiert gleichfalls auch den

”undefinierten“ Strom. Er reprasentiert die

Situation, in der in einem unbeschrankten (unendlichen) Zeitraum nichts ubertragenwird. Zu jedem endlichen Zeitpunkt konnen wir nur beobachten, dass soweit nichtsubertragen wurde, aber wir konnen nicht wissen, ob spater noch etwas ubertragenwird. Wir wissen nicht, ob der Strom

”leer bleibt“. Wenn wir auf eine Ubertragung

warten, die nie eintritt, terminiert der Vorgang nicht. Der leere Strom reprasentiertsomit eine

”nichtterminierende“ Berechnung, eine Kommunikation ohne Ergebnis.

Fur eine gegebene Menge M bezeichnet M∞ die Menge der unendlichen Sequenzenuber M. Diese entsprechende Abbildungen N→ M.

Mω entspricht also den endlichen und unendlichen Sequenzen von Elementen aus Mohne ⊥. Auf der Menge der Strome verwenden wir die folgenden charakteristischenFunktionen:

84 18. Marz 2014

3.3. Strome und stromverarbeitende Funktionen

& : α × Stream α→ Stream α,rest : Stream α→ Stream α,first : Stream α→ α,〈〉 : Stream α,

mit den Axiomen fur x ∈ M\{⊥}

first(x & s) = x,⊥ & s = 〈〉,rest(x & s) = s.

Die zweite Gleichung modelliert folgende Regel: Soll das Ergebnis einer Berechnungubertragen werden, die nicht terminiert, so ist der Nachrichtenstrom zwangslaufigleer, genauer undefiniert.

Eine etwas trickreiche Frage ist, welchen Strom ⊥ reprasentiert. Streng genom-men reprasentiert ⊥ den nichtdefinierten Strom, also ein Kommunikationsverhaltenbei dem nicht festgelegt ist, ob uberhaupt oder welche Nachrichten auftreten. DieAussage

”Der Ausgabestrom ist ⊥“ entspricht damit der Aussage: Es ist nichts uber

die Ausgabe bekannt. Die Aussage”Der Ausgabestrom ist 3&4&⊥“ entspricht der

Aussage: Die ersten beiden Ausgaben sind 3 und 4, daruberhinaus ist nichts uberden Ausgabestrom bekannt.

Achtung: Der Operator & ist nicht strikt sondern lediglich linksstrikt. Es giltauf Grund der nicht gegebenen Rechts-Striktheit des &-Operators:

1 & 3 & ⊥ & 10 & ... 6= ⊥ und 1 & 3 & ⊥ & 10 & ...6= 〈〉,sowie 1 & 3 & ⊥ & 10 & ... = 1 & 3 & 〈〉 = 〈1, 3〉.

Auf Stromen ist – wie auch auf Sequenzen– als eine vorherrschende Operation dieKonkatenation3

: Stream α × Stream α→ Stream α

definiert und durch die Gleichung

(x & s1)s2 = x & (s1s2)

spezifiziert. Bemerkenswerterweise gilt nach dieser Definition fur unendliche Stromex die Gleichung

xy = x

3Wir verwenden statt den Zeichen”◦“ fur die Konkatenation auf Sequenzen das Zeichen fur

die Konkatenation auf Stromen.

18. Marz 2014 85


Mit Hilfe der Konkatenation auf Stromen kann die Prafixordnung auf Stromen durchdie Formel

s1 v s2 ≡ ∃ s0 ∈ Mω: s1s0 v s2

besonders einfach charakterisiert werden.Die Prafixordnung v ist in der Tat eine partielle Ordnung. Die leere Sequenz 〈〉

ist das kleinste Element in dieser Ordnung. Die Menge der Strome hat bezuglich derPrafixordnung noch eine weitere bemerkenswerte Eigenschaft: Jede Kette

{si ∈ Mω: i ∈ N}

mit si v si+1 fur alle i ∈ N hat eine kleinste obere Schranke. Die partielle Ordnung(Mω, v) ist somit kettenvollstandig und erfullt damit alle Voransetzungen zur Bil-dung von Fixpunkten.

Achtung: Jeder unendlicher Strom kann durch eine Kette endlicher Stromeals Grenzwert (kleinste obere Schranke) dargestellt werden (analog dazu konnen wirjede reelle Zahl durch einen Grenzwert einer Folge rationaler Zahlen darstellen).Die Menge der Strome geordnet mit der Prafixordnung ist kettenvollstandig mitkleinstem Element 〈〉.

Nach dem Theorem von Knaster-Tarski (vgl. [Tar55]) gilt dann: Monotone Funk-tionen auf Stromen haben kleinste Fixpunkte.

3.4. Stromverarbeitende Funktionen

Eine einfache Sicht auf das Schnittstellenverhalten interaktiver Systeme erhaltenwir, wenn wir festlegen, dass jedes System n Eingange und m Ausgange (Kanale,Anschlusse) besitzt, die durch Sorten markiert sind. Uber diese Kanale fließen Da-tenstrome von Datenelementen der angegebenen Sorten.

Ein System stellen wir graphisch als ein Rechteck und die Kanale als Pfeile dar.Uber die Eingange und Ausgange fließen Strome von Nachrichten der entsprechen-den Sorte, wobei jeder einzelne Ein/Ausgang (Kanal) diese Nachrichten streng se-quentiell ubertragt. Ein graphisches Symbol eines solchen Systems zeigt die Abb.3.1.Uber die Eingange und Ausgange des Systems fließen Strome von Nachrichten derentsprechenden Sorte, wobei jeder einzelne Ein/Ausgang (Kanal) diese Nachrichtenstreng sequentiell ubertragt.

Diese Vorstellung vom Verhalten eines Systems wird durch stromverarbeitendeFunktionen modelliert. Das Verhalten eines Systems entspricht einer Funktion

f: Stream T1 × . . .× Stream Tn → Stream M1 × . . .× Stream Mm

86 18. Marz 2014


f

……

x1 : T1

xn : Tn ym : Mm

y1 : M1

Abb. 3.1.: Schnittstellensicht auf ein System mit Ein- und Ausgabekanalen

Seien dabei T1, . . . , Tn und M1, . . . , Mm die Sorten der Datenstrome, die uber dieEin- und Ausgange fließen.

Reale Systeme lesen Schritt fur Schritt ihre Eingabe (die Elemente ihrer Einga-bestrome) und erzeugen Schritt fur Schritt die Ausgabe (die Elemente der Ausga-bestrome). Stimmen in zwei Satzen von Eingabestromen die jeweiligen Anfangsse-quenzen uberein, so stimmen in den Ausgabenstromen ebenfalls die entsprechendeAnfangssequenzen uberein (Prinzip der Monotonie). Formal nehmen wir deshalb an,dass die Resultate der Funktion f, die das Verhalten eines Systems beschreibt, imSinne der Prafixordnung monoton und stetig von der Eingabe von f abhangen.

Formal definieren wir die Monotonie einer stromverarbeitenden Funktion wie folgt:

(y1, . . . , ym) = f(x1, . . . , xn)∧ (y′1, . . . , y′m) = f(x′1, . . . , x′n)∧ x1 v x′1 ∧ . . .∧ xn v x′n⇒ y1 v y′1 ∧ . . .∧ ym v y′m

Die Monotonie ist, wie wir spater sehen werden, eine wesentliche Eigenschaft um beider Komposition von Systemen mit Ruckkopplungskanalen die Verhaltensfunktionenfestzulegen. Das Prinzip der schrittweisen Berechnung wird durch das Konzept derStetigkeit erfaßt. Die Stetigkeit der monotonen Funktion f bezeichnet die folgendeEigenschaft:

Seien Ketten {x(j)i : i ∈ N}, 1 ≤ j ≤ n, fur die Eingangskanale gegeben. Es gilt

dann x(j)i v x

(j)i+1.

Wir definieren nun

(y(j)1 , . . . , y

(j)m ) = f(x

(j)1 , . . . , x

(j)n )

Die Monotonie von f stellt sicher, dass die so definierten {y(j)i : i ∈ N}, 1 ≤ j ≤ n,

ebenfalls Ketten bilden. Wir definieren4

x(j) = lub {x(j)i : j ∈ N}

4 lub – der kleinste Fixpunkt (engl. least upper bound)

18. Marz 2014 87


Sei (y1, . . . , ym) = f(x1, . . . , xn), die Monotonie garantiert, dass

lub { y(j)i : j ∈ N} v yi

gilt. Die Stetigkeit der Funktion f stellt sicher, dass auch folgende Gleichung gilt:

yi = lub { y(j)i : j ∈ N}

Wird die Funktion f als prafixmonoton und prafixstetig vorausgesetzt, bedeutet dies,dass eine Verlangerung der Eingabestrome hochstens zu einer Verlangerung der Aus-gabestrome fuhren kann und die Ausgabestrome als Grenzwete der Ausgaben aufendliche Prafixen der Eingaben festgelegt sind.

Beispiel 3.2: Einfache stromverarbeitende Funktionen (Datenflußfunktionen)

(1) Die Funktion

fct rest: Stream α→ Stream α

wie beschrieben im Abschnitt zur Einfuhrung der Strome.

(2) Elementweise Addition von Stromen von Zahlen

Die folgende Funktion dient der elementweisen Addition der Elemente zweierZahlenstrome

fct sadd = (s1, s2: Stream Nat) Stream Nat:(first(s1) + first(s2)) & sadd(rest(s1), rest(s2))

Die Funktion sadd kann als Beschreibung des Schnittstellenverhaltens einesAddierwerks verstanden werden, das auf Stromen von Zahlen arbeitet.

(3) Summation

Die folgende Funktion sum bildet einen Strom auf den Strom der Summe seinerPrafixe ab.

fct sum = (s: Stream Nat) Stream Nat:first(s) & sum((first(s) + first(rest(s))) & rest(rest(s)))

Eine andere Beschreibung der Funktion sum erhalten wir durch Einfuhrungeiner Hilfsfunktion sumk

88 18. Marz 2014


fct sumk = (n: Nat, s: Stream Nat) Stream Nat:n & sumk(n+ first(s), rest(s))

und durch die Gleichung

sum(s) = sumk(first(s), rest(s))

Man beachte die besondere Form der Rekursion in der Spezifikation der Funk-tion sumk. Wir illustrieren die Wirkweise der Funktion sum kurz. Nehmen wireinen einfachen Fall: Wir betrachten einen endlichen Strom

s = 〈1, 2, 3, 4, 5, 6, 7〉.

Die Summe aller Elemente dieses Stroms ist

1 + 2 + 3 + 4 + 5 + 6 + 7 = 28

Berechnen wir zuerst den Strom s mit der Funktion sum:

sum(s) = first(s) & sum((first(s) + first(rest(s))) & rest(rest(s)))= 1 & sum(3 & 〈3, 4, 5, 6, 7〉)= 1 & 3 & sum(6 & 〈4, 5, 6, 7〉)= 1 & 3 & 6 & sum(10 & 〈5, 6, 7〉)= 1 & 3 & 6 & 10 & sum(15 & 〈6, 7〉)= 1 & 3 & 6 & 10 & 15 & sum(21 & 〈7〉)= 1 & 3 & 6 & 10 & 15 & 21 & sum(28 & 〈〉)

// = sum(28 & 〈〉) = 28 & sum((28 + first(〈〉)) & rest(〈〉))// = 28 & sum((28 + ⊥)& 〈〉) = 28 & 〈〉

= 1 & 3 & 6 & 10 & 15 & 21 & 28 & 〈〉= 〈1, 3, 6, 10, 15, 21, 28〉

Berechnen wir jetzt den gleichen Strom s mit der Funktion sumk:

sumk(first(s), rest(s)) = sumk(1, 〈2, 3, 4, 5, 6, 7〉)= 1 & sumk(3, 〈3, 4, 5, 6, 7〉)= 1 & 3 & sumk(6, 〈4, 5, 6, 7〉)= 1 & 3 & 6 & sumk(10, 〈5, 6, 7〉)= 1 & 3 & 6 & 10 & sumk(15, 〈6, 7〉)= 1 & 3 & 6 & 10 & 15 & sumk(21, 〈7〉)= 1 & 3 & 6 & 10 & 15 & 21 & sumk(28, 〈〉)

// sumk(28, 〈〉) = 28 & sumk(28 + first(〈〉), rest(〈〉))// = 28 & sumk(28 + ⊥, 〈〉) = 28 & 〈〉

= 1 & 3 & 6 & 10 & 15 & 21 & 28 & 〈〉= 〈1, 3, 6, 10, 15, 21, 28〉

18. Marz 2014 89


Schließlich kommen wir zu dem Ergebnis

sumk(1, 〈2, 3, 4, 5, 6, 7〉)= 〈1, 3, 6, 10, 15, 21, 28〉= sum(〈1, 2, 3, 4, 5, 6, 7〉)

Wir erkennen, dass sum(s) = sumk(0, s) gilt. Formal lasst sich diese Aussagedurch Induktion beweisen.

(4) Elementweise Multiplikation der Daten zweier Strome

Die folgende Funktion dient der elementweisen Multiplikation der Daten zweierStrome

fct smult = (s1, s2: Stream Nat) Stream Nat:(first(s1) ∗ first(s2)) & smult(rest(s1), rest(s2))

(5) Den unendlichen aufsteigenden Strom aller naturlichen Zahlen ≥ n konnen wirdurch den Aufruf enum(0) generieren. Dabei sei die Funktion enum wie folgtdefiniert:

fct enum = (n: Nat) Stream Nat: n & enum(n+1)

(6) Speichern

Das Speichern von Datenelementen in einer Komponente kann durch folgendeFunktion beschrieben werden.

fct store = (c: Stream Bool, s: Stream Data) Stream Data:

mit den Axiomen

store(true & c, s) = first(s) & store(c, s)store(false & c, s) = store(c, rest(s))

Der Boolesche Eingabestrom steuert das Verhalten der Funktion store. DerWahrheitswert true dient dem Lesen des gespeicherten Wertes. Der Wahr-heitswert false bewirkt das Uberschreiben des gespeicherten Wertes durch denWert auf der Datenleitung.

(7) Differenzieren auf Stromen

Strome von naturlichen Zahlen konnen als diskretes Gegenstuck zu kontinu-ierlichen Funktionen auf reellen Zahlen aufgefasst werden. Das Konzept desDifferenzierens (Berechnen der Ableitung einer stetigen Funktion auf reellenZahlen) konnen wir auf Strome von ganzen (oder auch reellen) Zahlen ubert-ragen.

90 18. Marz 2014


fct diff = Stream Int → Stream Int

spezifiziert durch

diff(x & y & s) = (y – x) & diff(y & s)

Auch die Integration ist ubertragbar

fct integ = Int, Stream Int → Stream Int

spezifiziert durch

integ(z, x & s) = z & integ(z + x, s)

Beide Konzepte sind zueinander invers.

integ(x, diff(x & y & s))= integ(x, (y − x) & diff(y & s))= x & integ(y, diff(y & s))

daraus folgt durch Induktion

integ(first(s), diff(s)) = s

Analog lasst sich ein betrachtlicher Teil der Integrations- und Differentialrech-nung kontinuierlicher Funktionen auf Strome ubertragen. 2

Die Beispiele zeigen die Reichhaltigkeit der Theorie der Datenstrome. Das vorletz-te Beispiel zeigt bereits, dass auch Komponenten mit gekapselten Zustanden alsstromverarbeitende Funktion beschreibbar sind. Wir geben noch ein weiteres, etwaskomplizierteres Bespiel.

Beispiel 3.3: WarteschlangeAuch eine Komponente, die zur Verwaltung einer Warteschlange dient, kann alsstromverarbeitende Funktion

q: Stream M → Stream M

modelliert werden. Dies erfolgt uber die folgenden Axiome. Zunachst fuhren wir dieSorte der Nachrichten ein:

18. Marz 2014 91


sort M = Data ∪ { R©}

Das Signal R© kennzeichnet die Anforderung das nachste Element in der Warteschlan-ge auszugeben.

q(〈d〉z R©x) = 〈d〉q (zx) ⇐ z ∈ Data∗

q(z) = 〈〉 ⇐ z ∈ Data∗

Durch die Gesetze wird keine Funktion eindeutig beschrieben. Die Gesetze lassendie Funktion unterspezifiziert. Es wird nichts festgelegt fur das Ergebnis von q( R© &x). 2

Das Beispiel zeigt bereits, wie durch einfache Gleichungsaxiome interaktive Systemebeschrieben werden konnen. Aber auch unendliche Strome selbst lassen sich durchgeeignete Gleichungen beschreiben.

Die Prafixmonotonie stellt die Existenz von kleinsten Fixpunkten fur stromver-arbeitende Funktionen sicher. Somit konnen wir unendliche Strome durch rekursiveGleichungen beschreiben.

Beispiel 3.4: Rekursive Gleichungen fur Strome

(1) Wir betrachten die rekursive Gleichung (Deklaration des Stroms s):

Stream Nat s = 1 & s

Der einzige Strom, der diese Gleichung erfullt, ist der unendliche Strom, derden Wert 1 unendlich oft enthalt. Es gilt s = 〈1, 1, 1, ...〉. Man beachte, dass1 & ⊥ 6= ⊥ gilt. Ware der Operator & strikt und wurde somit 1 & ⊥ = ⊥gelten, ware der undefinierte Strom ⊥ die kleinste Losung (der schwachsteFixpunkt) der Gleichung fur s.

(2) Sei die Funktion sum wie oben spezifiziert. Die Gleichung

Stream Nat s = sum(1 & s)

hat folgende Losung (berechnet durch Auffalten)

s =sum(1 & s) =1 & sum((1 + first(rest(1 & s))) & rest(rest(1 & s))) =1 & sum((1 + first(s)) & rest(s)) =1 & sum((1 + 1) & rest(s)) = {da first(s) = 1}1 & 2 & sum((2 + first(rest(s))) & rest(rest(s))) =1 & 2 & sum(3 & rest(rest(s))) = . . .

92 18. Marz 2014


Wir erkennen, dass wir fur s den Strom aller partiellen Summen des Stromes 1 & 1& 1 & . . . erhalten und damit den Strom aller Zahlen. 2

Das Beispiel zeigt, wie sich unendliche Strome unmittelbar durch Rekursion de-finieren lassen und wie einfach wir auch mit unendlichen Stromen Rechnungendurchfuhren konnen. Auch die Struktur von Systemen konnen wir durch Stromeund stromverarbeitende Funktionen beschreiben, wie das folgende Beispiel zeigt.

Beispiel 3.5: Erzeuger/Verbraucher mit StromenSei Box eine Sorte zum Speicherung von Elementen, in unserem Beispiel zum Spei-cherung der verbrauchten Elementen. Mit den beiden Funktionen

fct produce = (x: Product) Stream Product:if last product(x) then x & 〈〉

else x & produce(next product(x))fi

fct consume = (y: Stream Produkt, z: Box) Box:if last product(first(y)) then consume(rest(y), put in box(first(y), z))

else bfi

erhalten wir zwei Beschreibungen von stromverarbeitenden Komponenten. Dabeiseinen put in box und next product vorgegebenen Funktionen und last product eingegebenes Pradikat.

Sei b der Zustand der Box zu Beginn. Wir konnen die Funktionen in folgendenDeklarationen von Stromen verwenden:

Stream Product y = produce(x0)Box b = consume(y, emptybox)

Dies modelliert die Erzeuger/Verbrauchersituation. 2

Eine beruhmte Aufgabe fur die Programmierung ist das Sieb des Erathostenes zurBerechnung der Folge aller Primzahlen in aufsteigender Reihenfolge. Sie lasst sichelegant mit Stromen darstellen.

Beispiel 3.6: Das Sieb des EratosthenesDen unendlichen Strom aller Primzahlen wollen wir durch den Strom

erastosthenes

bezeichnen, wobei der Strom erastosthenes wie folgt rekursiv definiert sei:

Stream Nat erastosthenes = sieb(enum(2))

18. Marz 2014 93


und die Funktion sieb gegeben ist durch (sei die Funktion enum wie oben definiert)die Deklaration:

fct sieb = (s: Stream Nat) Stream Nat:first(s) & sieb(elim(first(s), s))

Die Hilfsfunktion elim eliminiert im Aufruf elim(u, s) im Strom s alle Zahlen, diedurch die Zahl u teilbar sind. Sie ist durch folgende Deklaration gegeben:

fct elim = (n: Nat, s: Stream Nat) Stream Nat:if n divides first(s) then elim(n, rest(s))

else first(s) & elim(n, rest(s))fi

Dies ergibt eine sehr einfache, knappe, elegante Formulierung des Programms zurBerechnung des Siebs des Erathostenes. 2

Dieses einfache Beispiel zeigt bereits die Machtigkeit der Ausdrucksmittel beim Ein-satz von stromverarbeitenden Funktionen. Neben Berechnungen von nicht abbre-chenden, unendlichen Folgen von Werten konnen stromverarbeitende Funktionenfur die Modellierung des Ein/Ausgabeverhaltens verteilter Systeme eingesetzt wer-den.

Strome eignen sich auch zur Modellierung von Systemstrukturen wie etwa demZusammenwirken von Benutzer und Programm in einem Dialog.

Beispiel 3.7: Nutzer und Programm als stromverarbeitende FunktionenDas Verhalten des Benutzers eines Systems und des Systems selbst entsprechen denFunktionen:

fct user = (Stream Output s, t: userstate) Stream Input:if enough(first(s), t) then 〈〉

else newinput(first(s), t ) &user(rest(s), newuserstate(first(s), t))

fifct system = ( Stream Input s, t: Systemstate) Stream Output:

if ready(first(s), t) then 〈〉else newoutput(first(s), t) &

system(rest(s), newsystemstate(first(s), t))fi

Das Zusammenwirken von Nutzer und System definieren die verschrankt rekursivenGleichungen:

94 18. Marz 2014

3.5. Zusammenhang zur Objektorientierung

Stream Output systemoutput = system(userinput, initialsystemstate),

Stream Input userinput = initialinput & user(systemoutput, initialuserstate).

Dieses Zusammenwirken von durch stromverarbeitende Funktionen beschriebenenSystemen kann graphisch durch ein Datenflussdiagramm dargestellt werden, wie esin Abb. 3.2 gegeben ist. Die Kanten reprasentieren Datenstrome. 2

Das Zusammenwirken zwischen Nutzer und Programm ist ein einfaches Beispiel einesverteilten Systems mit zwei Teilsystemen (Komponenten). Wir kommen darauf inKapitel 4 im Detail zuruck.

In ahnlicher Weise wie im obigen Beispiel konnen wir stets das Zusammenwirkenvon Systemen modellieren und auch graphisch darstellen. In der Praxis werden dazuDatenflussdiagramme verwendet. Dieses Thema behandeln wir ausfuhrlicher unterdem Stichwort Struktursicht und Architektursicht.

user

system

userinput

systemoutput

Abb. 3.2.: Datenflußnetz fur Nutzer und Programm

Beispiele fur stromverarbeitende Funktionen finden wir auch unter anderem im Zu-sammenhang mit Booleschen Schaltwerken. Schaltwerke konnen wir als Komponen-ten verstehen, die auf Stromen von Wahrheitswerten arbeiten.

3.5. Zusammenhang zur Objektorientierung

Auch Objekte konnen als stromverabeitende Funktionen aufgefasst werden, um inihrer Außensicht modelliert zu werden. Das Verhalten eines Objekts wird durch eineKlasse festgelegt. Die Nachrichten in den Eingabestromen entsprechen Methodenauf-rufen und die in den Ausgabestromen den Ruckgabewerten fur die Methodenaufrufe.Wir konnen Methodenaufrufe dabei als Nachrichten auffassen:

Sort Call = methcall(name : MethodId, par : Parameters)Sort Return = callreturn(name : MethodId, par : Parameters, ret : ReturnValues)

18. Marz 2014 95


Damit erhalten wir folgende stromverarbeitende Funktion

f: Stream Call → Stream Return

die das Verhalten des Objekts als stromverarbeitende Funktion beschreibt.

Beispiel 3.8: SpeicherzelleWir betrachten eine einfache Klasse, die eine Speicherzelle beschreibt:

Class Store{ v : var Data

method put = (x : Data): v := xget = (y : var Data): x := v

}

Wir erhalten

f : Stream Call → Stream Return

mit den Axiomen:

f(〈methcall(put,d)〉〈methcall(get,y)〉 x) =〈callreturn(put,d, ε)〉〈callreturn(get,y, d)〉 rest(f(〈methcall(put,d)〉 x))

f(〈methcall(put,d)〉〈methcall(put,d′)〉 x) =〈callreturn(put,d, ε)〉 f(〈methcall(put,d′)〉 x)

Die beiden Gleichungen charakterisieren die Funktion auf Stromen von Aufrufen undRuckkehrnachrichten, die dem Schnittstellenverhalten der Speicherzelle entspricht.

2

Wir setzen bisher voraus, dass ein Methodenaufruf nicht auf Unteraufrufe von Me-thoden anderer Objekte fuhrt. Andernfalls mussen Unteraufrufe in Nachrichten ver-wandelt werden. Wir redefinieren dazu folgende Sorten:

Sort Call = methcall(oid: ObjectId, name : MethodId, par : Parameters)Sort Return = callreturn(oid: ObjectId, name : MethodId,

par : Parameters, ret : ReturnValues)Sort Message = Call | Return

Damit erhalten wir folgende stromverarbeitende Funktion:

f: Stream Message → Stream Message

Diese stromverabeitende Funktion beschreibt die Reaktionen des Objekts als Reak-tion auf Methodenaufrufe und Ruckkehrnachrichten.

96 18. Marz 2014

3.6. Spezifikation von Stromen

3.6. Spezifikation von Stromen

Strome beschreiben den Nachrichtenaustausch zwischen Teilsystemen. Eine Spezi-fikation eines Stromes uber einer vorgegebenen Grundmenge kann im Prinzip mitden gleichen Konzepten erfolgen, die fur die Beschreibung sequentieller Programmeverwendet werden. Wie vielfaltig die Moglichkeiten der logischen Beschreibung vonStromen sind, demonstrieren wir an einem einfachen Beispiel.

Beispiel 3.9: Der Strom der naturlichen ZahlenWir beschreiben den Strom der naturlichen Zahlen durch eine Reihe unterschiedli-cher logischer Techniken. Beispiele sind:

(1) first(s) = 0 ∧ ∀ s′: Stream Nat, n: Nat: s′〈n〉 v s ⇒ s′ 〈n〉〈n +1〉 v s

(2) s = 0 & succ∗(s)where

fct succ∗ = (Stream Nat s) Stream Nat: succ(first(s)) & succ∗(rest(s))

(3) s = f(0)where

fct f = (n: Nat) Stream Nat: n & f(succ(n))

(4) ∀ i: Nat: itrest(s, i) = iwhere

fct itrest = (s: Stream Nat, i: Nat) Nat:if i = 0 then first(s)

else itrest(rest(s), i − 1)fi

Dies spezifiziert eine Funktion itrest, die iteriert die Restfunktion anwendet. 2

Oft ist es notig, bestimmte Eigenschaften von Stromen zu beschreiben, die wir furdie Eingabestrome einer Komponente voraussetzen, damit diese korrekt arbeitet.

Beispiel 3.10: Spezifikation der Bedingungen an die Eingabe fur eine Warte-schlangeDie Eingabe an eine Warteschlange ist ein Strom x der Sorte Stream M mit

M = Data ∪ { R©}

Die Eingabe nennen wir zulassig, wenn von der Warteschlange nie Daten in einemZustand angefordert werden, in dem die Warteschlange leer ist:

∀ z ∈ Stream M: z v x ⇒ #(z, Data) ≥ # (z, R©)

18. Marz 2014 97


Diese Formel definiert eine”Sicherheitseigenschaft“ (eine genaue Definition des Be-

griffs Sicherheitseigenschaft erfolgt spater), die eine Annahme (engl.”Assumption“)

fur die Eingabe darstellt. Die Formel definiert eine formale Sprache (die Menge derendlichen Strome, die diese Formel erfullen). 2

Typische Hilfsfunktionen fur die Spezifikation von Stromen sind die Langenfunktion

| | : Stream α→ N ∪ {∞}

mit (fur x∈ M ∧ x 6= ⊥)

|〈〉| = 0,|x & s| = 1 + |s|

und die Filterfunktion

filter : p(α) × Stream α → Stream α

mit

filter(M, 〈〉) = 〈〉filter(M, x & s) = filter(s) fur x /∈ M ∧ x 6= ⊥filter(M, x & s) = x & filter(s) fur x ∈ M ∧ x 6= ⊥

Damit haben wir bereits erste Beispiele fur die Spezifikation stromverabeitenderFunktionen gegeben. Weitere folgen im nachsten Kapitel.

3.7. Spezifikation stromverarbeitender Funktionen

Wie allgemein Funktionen lassen sich stromverarbeitende Funktionen mit Hilfe fol-gender Techniken spezifizieren:

(1) rekursive Definitionen,

(2) Gleichungsformeln,

(3) Allgemeine Pradikate uber die Relation zwischen Eingabe- und Ausgabestrom(einschließlich temporale Logik).

Nichtdeterministische Komponenten (Knoten in einem Datenflußgraph) lassen sichdurch Mengen von stromverarbeitenden Funktionen oder durch mengenwertige Funk-tionen beschreiben.

Beispiel 3.11: Spezifikation stromverarbeitender FunktionenWir geben zwei Versionen von Spezifikationen fur eine Funktion

98 18. Marz 2014


f: Stream Nat, Set Nat → Stream Nat

an, die durch den Aufruf f(s, m) jedes zweite Vorkommen eines Elements x im Stroms, falls x ∈ m, loscht und falls x /∈ m, das erste Vorkommen und im ubrigen Stromjedes zweite.

(1) Rekursive Definition

fct f = (s: Stream Nat, m: Set Nat) Stream Nat:if first(s) ∈ m then first(s) & f(rest(s), m \ {first(s)})

else f(rest(s), m ∪ {first(s)})fi

(2) Spezifikation durch Axiome

x ∈ m ⇒ f(x & s, m) = x & f(s, m \ {x})x /∈ m ⇒ f(x & s, m) = f(s, m ∪ {x})

2

Die Beschreibung komplexer stromverarbeitender Funktionen kann außerst schwie-rig sein. Dies ist nicht erstaunlich, da sich uber stromverarbeitende Funktionen imPrinzip die ganze Vielfalt interaktiver Komponenten beschreiben lasst. Wichtig da-bei ist die geschickte Wahl der Beschreibungstechnik und des Spezifikationsstils.

Beispiel 3.12: Spezifikation stromverarbeitender Funktionen

(1) Mischfunktion

Eine Mischfunktion dient dazu, zwei Strome in einen Strom zusammenzumi-schen. Sie wird wie folgt beschrieben:

merge: Stream α, Stream α→ Stream α

Die charakteristischen Gleichungen sind nachfolgend angegeben:

merge(x, y) = first(x) & merge(rest(x), y) ∨merge(x, y) = first(y) & merge(x, rest(y))

Diese Formel beschreibt die Mischfunktion nicht eindeutig. Mit anderen Wor-ten, es existieren viele Funktionen, die alle die obige Gleichung erfullen. Jededieser Funktionen verdient die Bezeichnung Mischfunktion. Sind beide Einga-bestrome unendlich, so erzeugt jede Mischfunktion einen unendlichen Strom.Allerdings ist eine so spezifizierte Mischfunktion nicht notwendigerweise

”fair“,

denn im Extremfall werden nur die Elemente eines der beiden Strome beruck-sichtigt.

18. Marz 2014 99


(2) Aufspalt-Funktion fork

Sei die Sorte A = B ∪ C. Die Funktion fork spaltet einen Strom von Elementenvom Typ A in zwei Stromen vom Typen B und C auf.

fct fork = (a: Stream A) (Stream B × Stream C)if first(a) ∈ B then (〈first(a)〉, 〈〉) fork(rest(a))

else (〈〉, 〈first(a)〉) fork(rest(a))fi

(3) Unzuverlassige Ubertragungsfunktion

Bei der Beschreibung von Systemen zur Ubertragung von Informationen inTelekommunikationsanwendungen sind wir haufig auch daran interessiert, dasVerhalten moglicherweise fehlerhafter Systeme zu beschreiben (vgl.

”Alternating-

Bit“-Protokoll, Abschnitt 1.5). Erforderlich ist dabei die prazise Beschreibungwelche Arten von Fehlern auftreten konnen, um entsprechende Fehlerkorrek-turverfahren vorsehen zu konnen. Wir beschreiben nun eine einfache Ubertra-gungsfunktion:

transmit: Stream α → Stream α

Wir spezifizieren eine Ubertragungsfunktion, die gewisse Nachrichten im zuubertragenden Nachrichtenstrom verlieren kann, aber Nachrichten weder verfalscht,keine zusatzlichen Nachrichten hinzufugt oder die Reihenfolge andert. Bei derfehlerhaften Ubertragungsfunktion mit Fehlerelement wird ein Element in einFehlerelement umgewandelt. Somit kann der Empfanger Fehler bemerken. Wirspezifizieren die Ubertragungsfunktion so, dass sie fair ist, d.h. nach Fehlerntreten immer wieder erfolgreich ubertragene Elemente auf.

(3a) Ohne Fehlerelement:

∃ oracle: Stream Bool:|oracle| = ∞ ∧ transmit(s) = filter(oracle, s) ∧ filter({true}, oracle) = ∞

(3b) Mit Fehlerelement:

∃ oracle: Stream Bool:|oracle| = ∞ ∧ transmit(s) = schedule(oracle, s) ∧ filter({true}, oracle) = ∞

where

100 18. Marz 2014


schedule: Stream Bool, Stream α→ Stream α

schedule(true & c, s) = first(s) & schedule(c, rest(s))schedule(false & c, s) = error & schedule(c, rest(s)) 2

Diese Form der Beschreibung von Schnittstellenverhalten nutzt abstrakte logischeSpezifikationen. Suggestiv sind in vielen Fallen so genannte Assumption/Commit-ment-Spezifikationen (manchmal auch Assumption/Guarantee-Spezifikationen ge-nannt). Dabei beschreiben wir die Anforderungen an ein Systemverhalten durch Assumption/

Commitment-

Spezifikation

Assumption/Guarantee-Spezifikation

zwei Pradikate, eine Annahme (Assumption), die festlegt, welche Eigenschaften furdie Eingabestrome gefordert werden, damit das System ordnungsgemaß arbeitetund ein Zusagepradikat (Commitment), das ausdruckt, was ein ordnungsgemaßesVerhalten ist. Ein typisches Beispiel fur diese Art der Spezifikation liefert ein unbe-schrankter Puffer.

Beispiel 3.12: Spezifikation stromverarbeitender Funktionen (Fortsetzung)

(4) Filtern eines StromesSei Sorte M = Data ∪ { R©}. Eine Funktion, die aus ihrem Eingabestrom s,der eine Eingabe fur eine Warteschlange darstellt, diejenigen Anforderungenloscht, die nicht korrekt sind, da die Anforderung sich auf nicht vorhandeneDaten bezieht, kann durch delete(s, 0) wie folgt spezifiziert werden:

fct delete = (s: Stream M, n: Nat) Stream M:if first(s) = R© then if n = 0

then delete(rest(s), n)else first(s) & delete(rest(s), n − 1)

else first(s) & delete(rest(s), n + 1)fi

Die Funktion delete(s, 0) loscht im Strom s alle Anforderungssignale R©, die andie leere Warteschlange gerichtet sind.

Mit Hilfe dieser Funktion konnen wir eine”Assumption“

asm: Stream M → Bool

definieren

asm(x) ≡ (x = delete(x, 0))

Damit konnen wir die Funktion

q: Stream M → Stream Data

18. Marz 2014 101


wie folgt spezifizieren

∀y ∈ q(x) : asm(x) ⇒ com(x, y)

wobei

com(x, y) = (y v filter(Data, x) ∧ #y = #filter({ R©}, x))

(5) Allgemeine Spezifikation eines”Datenpool“

Ein Datenpool dient der Speicherung von Datenelementen der Menge Dataund der Ruckgabe auf Anforderung.

Sort Data+ = Data | {req}q: Stream Data+ → Stream Data+

∀ z ∈ Stream Data: |z| ≥ 1 ⇒∃ a, b ∈ Stream Data, d ∈ Data:

|a| < ∞ ∧z = a〈d〉b ∧ q(z〈req〉x) = 〈d〉q(abx)

Dies liefert eine hochgradig unterspezifizierte Spezifikation der Funktion q. 2

Die Beispiele zeigen die Vielfalt stromverarbeitender Funktionen, aber auch einSpektrum von Moglichkeiten, diese zu spezifizieren.

3.8. Systeme mit benannten Kanalen

Da stromverarbeitende Funktionen in der Regel viele Eingabestrome und Ausgabe-strome besitzen, ist es in aller Regel bequem, statt mit Tupeln von Stromen zu arbei-ten, diese Strome uber Kanalidentifikatoren zu benennen und diese Identifikatorenals Teil der Schnittstelle zur Verfugung zu stellen. Nach dieser Konzeption bestehtdie syntaktische Schnittstelle einer Komponente aus zwei Mengen von Kanalidentifi-katoren und deren Sorten. Die eine Menge bezeichnet die Menge der Eingabekanaleund die zweite Menge die Menge der Ausgabekanale.

Sei C eine Menge von Kanalen (genauer von Kanalnamen), wobei fur jeden Kanalc ∈ C eine Sorte festgelegt sei. Eine Kanalbelegung x fur C ist eine Abbildung, diejedem Kanal c ∈ C einen Strom der Sorte Stream α zuordnet, falls c die Sorte α hat.Mit x.c bezeichnen wir den Strom der dem Kanal durch die Belegung x zugewiesenwird. Mit

−→C

bezeichnen wir die Menge aller Kanalbelegungen fur die Menge C. Seien C1 und C2

disjunkte Mengen von Kanalen. Fur x1 ∈ C1 und x2 ∈ C2 bezeichnen wir mit

102 18. Marz 2014

3.8. Systeme mit benannten Kanalen

x1 ⊕ x2

die Kanalbelegung in−→C mit C = C1 ∪ C2 definiert durch die Gleichung

(x1 ⊕ x2).c=

{x1.c falls c ∈ C1

x2.c falls c ∈ C2

Sei {c1, ..., cn} eine Menge von Kanalen und sein {s1, ..., sn} eine Menge vonStromen, so dass si eine Strom der Sorte ist, die dem Kanal ci zugeordnet ist. Mit

{c1 7→ s1, ..., cn 7→ sn}

bezeichnen wir die Kanalbelegung, die den Kanalen ci die Strome si zuordnet. DiePrafixordung auf Stromen ubertragt sich direkt auf Kanalbelegungen.

Das Verhalten einer deterministischen Komponente mit der Menge I von Einga-bekanalen und der Menge O von Ausgabekanalen ist durch die Funktion

f:−→I →

−→O

gegeben. Wieder nehmen wir an, dass die Funktion f prafixmonoton ist.Oft konnen Eigenschaften einer stromverabeitende Funktion auf benannten Kanalen

einfach durch eine logische Formel beschrieben werden, in der die Kanalnamen alsIdentifikatoren fur die entsprechenden Strome auftreten. Dabei setzen wir der Ein-fachheit halber voraus, dass die Identifikatoren fur Eingabe- und Ausgabekanaleverschieden sind.

Stromverarbeitende Funktionen mit benannten Kanalen sind besonders elegantdurch logische Formeln zu spezifizieren. Wir schreiben:

f : [ in x1 : T1, ..., xn : Tn, out y1 : M1 , ... , ym : Mm: E ]

mit der pradikatenlogischen Formel E, in der die Kanale fur Strome der entsprechen-den Sorte stehen. Dies bedeutet, dass f eine stromverarbeitende Funktion ist, derenKanalbelegungen die Formel E erfullen.

Beispiel 3.13: Spezifikation des Systems BarrierWir spezifizieren das System Barrier mit den Eingabekanalen x der Sorte Data undy der Sorte Ack mit Tragermenge {ack} und dem Ausgabekanal z der Sorte Datawie folgt:

Barrier : [ in x: Data, y: Ack, out z: Data: #z = min(#x, #y) ∧ z v x ]

Diese Formel spezifiziert das Verhalten eines Systems, das die Eingaben auf Kanalx auf Kanal y ausgibt, wobei die Zahl durch die Nachrichten in z beschrankt wird.

Eine grafische Darstellung von Systems Barrier einschließlich der spezifizierendenFormel ist in der Abb. 3.3 gegeben.

18. Marz 2014 103


Barrier#z = min(#x, #y) ∧ z v xx: Data

y: Ackz: Data

-

-

-

Abb. 3.3.: Grafische Darstellung des Systems Barrier

2

Durch diese Notation konnen wir Verhalten einfach in der Form einer Relation zwi-schen Belegungen der Eingabekanale und Belegungen der Ausgabekanale spezifizie-ren.

Jede Funktion f kann umgekehrt auch als logische Aussage uber die Kanale ver-standen werden. Wir schreiben

[ f ]

fur die Aussage f(x) = y mit I = {x1, . . . , xn} und O = {y1, . . . , ym}. Wir erhalten:

[ Barrier ] = (#z = min(#x, #y) ∧ z v x)

[ Barrier ] entspricht einer pradikatenlogischen Formel mit den Kanalnamen als freieVariable.

2

Jede Funktion f′ der Funktionalitat

f′ : Stream T1 × . . .× Stream Tn → Stream M1 × . . .× Stream Mm

kann durch die Einfuhrung von Bezeichnungen x1, . . . , xn und y1, . . . , ym fur Kanaleund die Festlegung

f: [ in x1: T1, . . . , xn: Tn, out y1 : M1, . . . , ym : Mm: (x1, . . . , xn) := f′(y1, . . . , ym) ]

in eine Funktion auf Kanalen umgewandelt werden. Umgekehrt kann jede Funktion

f:−→I →

−→O

auf Belegungen von Kanalen mit I = x1, . . . , xn und O = y1, . . . , ym durch dieFestlegung

f′ = (x1 : Stream T1, . . . , xn : Stream Tn) (Stream M1, . . . , Stream Mm):(y1, . . . , ym) where [ f ]

in eine Funktion zwischen (unbenannte) Tupel von Stromen umgewandelt werden.Dies zeigt, dass zwischen stromverarbeitenden Funktionen mit oder ohne benannteKanale kein tiefgreifender Unterschied besteht. Lediglich bei der Formulierung derSpezifikationen ist diese Unterschied vor Belang.

Auch nichtdeterministische Systeme konnen wir durch die aufgefuhrten Technikenbeschreiben. Nichtdeterministische Systeme modellieren wir durch Mengen strom-verarbeitender Funktionen. In der Regel gibt es eine Reihe von Funktionen, die eineFormel erfullen.

104 18. Marz 2014

3.9. Schnittstellenabstraktion: Von stromverarbeitenden Funktionen zuZustandsmodellen und zuruck

3.9. Schnittstellenabstraktion: Von stromverarbeitenden

Funktionen zu Zustandsmodellen und zuruck

Im Folgenden beschranken wir uns aus Einfachheit auf deterministische Systeme.Eine Verallgemeinerung des gezeigten Vorgehens auf nichtdeterministische Systemeist ohne Probleme moglich.

3.9.1. Zustandsmaschinen zur Beschreibung stromverarbeitenderFunktionen

Durch stromverarbeitende Funktionen erhalten wir ein abstraktes Zustandskonzept.Ein Zustand ist durch die entsprechende Verhaltensfunktion gegeben. Umgekehrtkonnen wir einer Zustandsmaschine mit Eingabe und Ausgabe eine stromverarbei-tende Funktion zuordnen. Wir betrachten die Ubergangsfunktion (wir beschrankenuns wieder auf den deterministischen Fall):

∆: Σ × Input → Σ × Output

Wir definieren fur jeden Zustand eine stromverarbeitende Funktion durch die Ab-bildung

f: State → (Stream Input → Stream Output)

wobei fur jeden Zustand σ ∈ Σ die Funktion

fσ: Stream Input → Stream Output

spezifiziert wird durch (sei i ∈ Input, x ∈ Stream Input) die Gleichung

fσ(i &x) = o & fσ′(x)

wobei σ’ und o durch

(σ′, o) = ∆(σ, i)

definiert sind.Dadurch erhalten wir fur jeden Zustand der Maschine eine stromverarbeitende

Funktion, die das Ein-/Ausgabe-Verhalten der Maschine ausgehend vom diesen Zu-stand σ beschreibt.

Diese Konstruktion liefert eine Abstraktion fur Zustandsmaschinen. Sehr unter-schiedliche Zustandsmaschinen (Maschinen mit sehr unterschiedlichen Zustandsraum-en) konnen fur ihre Anfangszustande auf die gleichen Funktionen abgebildet werden(Schnittstellenabstraktion, Verkapselung des Zustandes).

Sei

18. Marz 2014 105


∆: Σ × Input → Σ × Output

eine Zustandsubergangsfunktion und sei σ ∈ State Anfangszustand, dann represen-tiert

fσ: Stream Input → Stream Output

das Schnittstellenverhalten (unabhangig vom Zustandsraum).

3.9.2. Stromverarbeitende Funktionen als Zustandsmaschinen

Stromverarbeitende Funktionen haben wir als Mittel der Schnittstellenabstraktioneingefuhrt. Sie entsprechen selbst unmittelbar abstrakten Zustandsmaschinen, wobeidie Funktionen selbst die Rolle der Zustande einnehmen. Dies gibt eine fundamenta-le Einsicht wieder. Jede stromverarbeitende Funktion beschreibt ein Verhalten desSystems und entspricht damit abstrakt dem Zustand des Systems, der auf diesesVerhalten fuhrt.

Sei Input eine Menge von Eingabenachrichten und Output eine Menge von Ausga-benachrichten. Wir zeigen diesen Ubergang nur fur den Spezialfall der Datenfluss-komponente mit einem Eingabestrom r und einem Ausgabestrom a:

f: Stream Input → Stream Output

Sei State die Menge aller monotonen Funktionen, die Strome der Sorte Input aufStrome der Sorte Output abbilden:

State = {h: Stream Input → Stream Output: h monoton}

Wir definieren eine Zustandsmaschine (vgl. Moore- und Mealy-Zustandsmaschinen)

∆: Σ × Input → Σ × Stream Output

durch die Gleichung

∆(h, a) = (h′, r)

wobei h, h′ ∈ State, a ∈ Input, r ∈ Stream Output und folgende Eigenschaften gelten:

r = h(〈a〉)h(a & x) = r h′(x) (x ∈ Stream Input)

h′ heißt Resumption (Fortsetzung) und ist durch diese Gleichung eindeutig be-Resumption(Fortsetzung) stimmt, falls Strom r endlich ist. Falls Strom r unendlich ist, definieren wir h′(x) = 〈〉

fur alle Eingabestrome x.Eine stromverarbeitende Funktion definiert damit gleichzeitig

106 18. Marz 2014

3.10. Schnittstellenbeschreibungen fur Zustandsmaschinen

� einen Zustand,

� einen Zustandsautomaten mit Ein- und Ausgabe.

Umgekehrt konnen wir auch Strome von Zustanden betrachten und Funktionen, dieStrome von Zustanden auf Strome von Zustanden abbilden. Uber diesem Modelllassen sich Programme modellieren, die mit gemeinsamen Variablen (gemeinsamerSpeicher) arbeiten.

Stromverarbeitende Funktionen mit benannten Eingabe- und Ausgabekanalen las-sen sich auch bequem durch zuweisungsorientierte Programme beschreiben. Damitergeben sich folgende Aspekte stromverarbeitender Funktionen:

� Ablaufe: Fur jeden Eingabestrom ergibt sich eine Menge von Ablaufen. Diesstellt eine Beziehung her zwischen ablauforientierter Modellierung und strom-verarbeitenden Funktionen (siehe spater).

� Zustandsmaschinen: Eine stromverarbeitende Funktion definiert eine Zustands-maschine mit Anfangszustand und der Menge der erreichbaren Zustande. Esergibt sich ein Zusammenhang zur objektorientierten Programmierung. Strom-verarbeitende Funktionen stellen ein sehr abstraktes Modell fur das Verhaltender Komponenten (Datenflussknoten) verteilter Systeme dar. Haufig sind wirjedoch an konkreteren Zustandsbeschreibungen interessiert.

3.10. Schnittstellenbeschreibungen fur Zustandsmaschinen

Um eine Schnittstellenabstraktion fur Zustandsmaschinen zu erhalten, die im In-teraktionsmodus uber gemeinsame Variable arbeiten, bietet es sich an, zwischenZustandsanderungen zu unterscheiden, die durch die Maschine selbst ausgefuhrtwerden, und solchen, die durch die Umgebung ausgefuhrt werden. Wir spezifizierensomit die Schnittstelle eines Systems, indem wir die Zustandsanderungen beschrei-ben, die das System ausfuhrt, und jene, die die Umgebung ausfuhren darf. Dazukann man eine Menge von Aktionen des Systems und der Umgebung definieren (sie-he [Lam94]). Wir sprechen von Assumption/Guarantee-Spezifikationen.

Beispiel 3.14: Warteschlangen als Zustandsmaschine mit markierten Ubergangen

Sei die Menge Data von Datenelementen gegeben. Ein Keller kann folgende MengeActionstack von Aktionen ausfuhren:

Actionstack = {initStack, pop} ∪ {top(d): d ∈ Data} ∪ {push(d): d ∈ Data}

Die Menge der Zustande definieren wir durch folgende Attribute:

18. Marz 2014 107


q : Data∗,empty: Bool,input : Data,output : Data,inready, outready : Bool.

Die Umgebung darf nur die Variablen inready, outready, empty, output lesen und nurauf die Variablen inready, outready und input schreiben. q ist also interne Variable.

Achtung: Fur jede Variable x bezeichnen wir den Zustand dieser Variable nacheiner Aktion mit x′.

Wir erhalten folgende Spezifikationen fur die Aktionen der Umgebung:

set(d): requires: inreadyguarantees: ¬ inready′ ∧ outready′ = outready ∧ input′ = d

get: requires: outreadyguarantees: ¬ outready′ ∧ inready′ = inready

Wir erhalten folgende Spezifikationen fur die Aktionen des Systems:

doset: requires: ¬ inreadyguarantees: inready′ ∧ outready′ = outready ∧ output = output′

∧ q′ = q inputdoget: requires: ¬ outready ∧ q 6= 〈〉

guarantees: outready′ ∧ inready′ = inready ∧ input = input′

∧ q′ = rest(q) ∧ output′ = first(q)

Hier modellieren wir die Warteschlange so, dass die Operation doget nur ausfuhrbarist, wenn die Warteschlange nicht leer ist. Dabei verwenden wir folgende Konvention:alle in Zusicherungen nicht erwahnten Variablen andern in einen Ubergang ihrenWert nicht.

Mit dieser Technik konnen die Schnittstellen zwischen Systemen, die auf gemeinsa-men Variablen arbeiten, spezifiziert werden. Dabei konnen in der Spezifikation auchInvarianten verwendet werden, die entweder vom System oder von der Umgebungeingehalten werden. Eine ausfuhrliche Theorie und Methodik fur diese Vorgehens-weise findet sich in [Lam94]. Dabei wird der Komposition von Komponenten, die indieser Weise beschrieben sind, besondere Aufmerksamkeit geschenkt.

3.11. Historische Bemerkung zu Schnittstellensichten

Die Idee der Schnittstelle ist fundamental fur die Informatik. Fruhe Arbeiten vonDavid Parnas weisen auf die Bedeutung der Schnittstellenspezifikation hin. Wich-tige Stichworte dabei sind Information Hiding, das Geheimnisprinzip, das deutlich

108 18. Marz 2014

3.11. Historische Bemerkung zu Schnittstellensichten

machen soll, das es fur die Nutzung eines Systems als Komponente in einem Sys-tem nicht notwendig ist, die Implementierungsdetails der Komponenten zu kennen,sondern dass es nur wichtig ist, die Nutzungsschnittstelle zu kennen. Dies hat denVorteil, dass dann Implementierungsdetails geandert werden konnen, ohne dass an-dere Systemteile betroffen sind, so lange nur die Schnittstelle unverandert bleibt.

Trotz dieser fruhen Erkenntnis der Wichtigkeit der Schnittstellen und der Be-tonung der Bedeutung von Schnittstellen in vielen praktischen Ansatzen sind dieFahigkeiten, Schnittstellen zu beschreiben, in den letzten Jahrzehnten nur sehr ein-geschrankt weiter entwickelt worden. Viele Modelle sind starker operational undso finden sich oft Schnittstellenbeschreibungen, in denen Schnittstellen nicht in dergroßtmoglichen Abstraktion dargestellt werden, sondern eher stellvertretend Imple-mentierungen angegeben werden, die entsprechenden Schnittstellen vorgeben unddie Schnittstellen durch Aquivalenzrelation charakterisieren.

Auch die in der Objektorientierung vorherrschende Idee der Ausgabe der Schnitt-stellen einer Klasse bzw. eines Objekts mit Hilfe der Methoden, die dafur zurVerfugung stehen zu verkapseln, ist praktisch nicht wirklich umgesetzt. Alle Spezifi-kationstechniken auf objektorientierten Sprachen, die bisher bekannt sind, beziehensich auch auf Implementierungsdetails wie etwa auf die Attribute der spezifiziertenKlasse, die fur die Schnittstelle selbst eigentlich ohne Bedeutung sein sollten.

Leslie Lamport betont in seinem Ansatz TLA (vgl. [Lam94]), dass die zustands-basierte Beschreibung des Systemverhaltens nur exemplarisch im Sinne eines ab-strakten Modells zu verstehen ist und dass bei TLA-Spezifikationen eben auch derSchnittstellengedanke im Vordergrund steht.

Eine konsequente Schnittstellenbeschreibung bieten Ansatze wie Focus (vgl.[BDD+92] und [BS01b]), bei denen die Ein/Ausgabe-Relationen zur Beschreibungder Schnittstelle dienen. Interessant ist in diesem Zusammenhang auch die Moglich-keit, Interaktionsdiagramme einzusetzen, um Schnittstellen zu beschreiben.

18. Marz 2014 109


3.12. Ubungsaufgaben

Ubungsaufgabe 3.1: Beschreiben Sie den Strom der 2-er Potenzen 〈20, 21, 22, . . . 〉mit Hilfe der unterschiedlichen Spezifikationstechniken.

Ubungsaufgabe 3.2: Beschreiben Sie ein System, das Daten der Sorte Dataspezifiziert und auf Anforderung durch das Signal

”flush“ ausgibt.

Ubungsaufgabe 3.3: Beschreiben Sie einen Sortierknoten, der einen Stromvon Daten der Sorte Data als Eingabe nimmt und mit Hilfe des Pradikates

p : Data→ Bool

in zwei Strome aufteilt, bestehend aus den Elementen, fur die p gilt und denen furdie p nicht gilt.

110 18. Marz 2014

4. Komposition, Struktur- undVerteilungssicht

In der Systementwicklung und Programmierung sind wir aus naheliegenden Grundenan einer strukturierten Beschreibung von Systemen, deren modularen Strukturie-rung in Teilsysteme sowie deren Zusammenwirken und deren Schnittstellenverhal-ten interessiert. Im Rahmen einer Systementwicklung zerlegen wir ein System ineinem Entwurf (Design) in geeigneter Weise in eine Reihe von Teilsystemen, die wirdie Komponenten des Systems nennen. Die Komponenten kooperieren, etwa durch Komponente

Nachrichtenaustausch, und bilden ein verteiltes System (eine Architektur).Diese Zerlegung kann wiederholt auf die Teilsysteme angewandt werden. Es ent-

steht eine hierarchische Zerlegung eines Systems in Teilsysteme. Dieses Vorgehennennen wir hierarchischen Top-Down-Entwurf. Setzen wir umgekehrt ein System auseiner Reihe vorgegebener Komponenten zusammen, so sprechen wir vom Bottom-Up-Vorgehen.

In beiden Fallen gilt: Die Komponenten kooperieren und/oder kommunizierenuntereinander und mit der Systemumgebung. Durch ihr Zusammenwirken entstehtdas Verhalten des Gesamtsystems.

Ein verteiltes System besteht aus einer Familie von Komponenten, die uber ge-meinsame Variable oder uber Kanale untereinander und auch mit der Systemumge-bung Informationen austauschen und sich auf diese Weise koordinieren und mitein-ander kommunizieren. Unter dem Stichwort Verteilung interessiert uns weniger dieraumliche Verteilung als die logische Untergliederung in Teilsysteme, die allerdingsdie Voraussetzung fur eine raumliche Verteilung ist.

Im Folgenden sind wir an der Darstellung der Struktur- oder Verteilungssichtinteressiert. Wir erhalten zur Darstellung des Datenflusses sogenannte Datenfluss-modelle (auch Pipes-and-Filters Architekturen genannt) fur verteilte Systeme. Ein Datenfluss-

modellDatenflussmodell wird anschaulich graphisch durch ein Datenflussnetz beschrieben(siehe Abb. 4.2). Ein interaktionsorientiertes Modell fur das Verhalten der Kom-ponenten (dargestellt durch Datenflussknoten) eines Datenflussnetzes erhalten wirdurch stromverarbeitende Funktionen.

4.1. Architekturen und verteilte Systeme

Ein verteiltes System besteht aus einer Familie von Komponenten, die untereinanderInformationen austauschen und so miteinander interagieren. Ist die Schnittstellen-

18. Marz 2014 111

Kapitel 4. Komposition, Struktur- und Verteilungssicht

spezifikation fur die Komponenten gegeben und weiter prazise festgelegt, wie dieKomponenten im Sinne des Informationsaustausches miteinander verbunden sind,so ist damit das Verhalten des verteilten Systems auf Architekturebene festgelegt.Wir gehen davon aus, dass die Komponenten eines verteilten Systems nebenlaufig,also parallel, agieren.

Es gibt viele Varianten der Interaktion, Modellierung und Beschreibung verteilterSysteme. Dabei ist von Bedeutung, wie die Komponenten und insbesondere derenSchnittstelle charakterisiert sind und auf welche Weise sie zusammenwirken.

4.1.1. Architekturen und zusammengesetzte Systeme

Ein zusammengesetztes System besitzt eine Architektur, die die Struktur des Sys-tems beschreibt. Die Struktur ist gegeben durch die in der Regel endliche Menge Kder Komponenten des Systems und die Angabe, welcher dieser Komponenten wieuntereinander oder mit der Systemumgebung verbunden sind.

Abb. 4.1 zeigt ein einfaches Verteiltes System S, genauer seine Struktur im Sinneder Untergliederung in die Teilsysteme A, B und C sowie deren Verbindung uberdie Kommunikationskanale a, b, c, d, e, f, g und h, die Teil der Schnittstellen derKomponenten sind. Dabei ist noch nichts zu der Frage ausgesagt, welcher Natur dieKomponenten sind und was die Schnittstellen im Sinne des Verhaltens des Systemsbedeuten.

SA C

B

a

c

d

h

f

b

eg

Abb. 4.1.: Einfaches verteiltes System

Jede Komponente eines Systems konnen wir selbst wieder weiter zerlegen. Abb 4.2zeigt die weitere Zerlegung der Komponente A in eine Reihe weiterer Teilsysteme.

Ebenso konnen wir die Komponenten B und C, aber auch die Teilkomponenten D,E, F und G von A weiter zerlegen. Es entsteht eine hierarchische Zerlegung und einKomponentenbaum, wie er in Abb. 4.3 dargestellt ist.

112 18. Marz 2014

4.1. Architekturen und verteilte Systeme

AD

a

f

b

g

E G

F

Abb. 4.2.: Zerlegung der Komponente A

S

GFED

CBA

… …

… … … …

Abb. 4.3.: Komponentenbaum

4.1.2. Parallele Komposition

Der vorangegangene Abschnitt beschreibt eine hierarchische Zergliederung von Sys-temen in Teilsysteme. Die so untergliederten Systeme nennen wir zusammengesetztoder verteilt. Verteilte Systeme ergeben sich aus der parallelen Komposition ih-rer Teilsysteme. Abhangig von der speziellen Wahl und Modellierung der Teilsyste-me und ihrer Schnittstellen wird die parallele Komposition definiert. Entsprechendkonnen wir verteilte Systeme durch parallele Komposition von

� Zustandsmaschinen mit Ein/Ausgabe

� Zustandsmaschinen mit gemeinsamen Speichern

18. Marz 2014 113


oder einer Reihe ahnlicher Konzepte zur Darstellung von Systemen definieren.Typisch ist dabei, dass nur Teilsysteme komponiert werden konnen, die syntak-

tisch zusammenpassen – genauer gesagt, fordern wir dass die syntaktischen Schnitt-stellen zusammenpassen. Nur dann entsteht ein syntaktisch korrektes Gebilde. DieBeschreibung des Verhaltens der Teilsysteme konnen uber abstrakte Schnittstellen-beschreibungen gegeben werden.

4.1.3. Modularitat

Das Verhalten eines verteilten Systems ergibt sich aus dem Verhalten seiner Teilsys-teme und daraus, wie das System aus den Teilsystemen zusammengesetzt ist – wirsprechen von der Struktur (der Verbindung, auch von den

”Konnektoren“) der Teil-

systeme. Wenn das Verhalten der Teilsysteme, etwa durch Modelle, so spezifiziertist, dass sich das Modell des Verhaltens des Gesamtsystems daraus durch Komposi-tion ermitteln lasst, so nennen wir den Ansatz zur Modellierung von Systemen undderen Komposition modular.

Eine Spezifikations- oder Modellierungskonzept fur zusammengesetzte Systemeheißt somit modular, wenn aus den Modellen bzw. Spezifikationen der Komponen-ten eines Systems das Verhalten des Gesamtsystems durch Komposition konstruiertwerden kann.

Modularitat ist nicht selbstverstandlich und nicht immer gegeben. Wir werdenBeispiele fur nichtmodulare Systemmodelle kennenlernen.

4.2. Datenflussnetze

Ein sehr elementares modulares Modell verteilter Systeme sind Datenflussnetze(auch

”Pipes and Filters“-Architekturen genannt). Dabei wird der Informations-

fluss zwischen den Komponenten eines Systems durch Kanalverbindungen und Da-tenstrome dargestellt.

4.2.1. Systeme als Datenflussnetze

Mit Hilfe der parallelen Komposition von Datenflußkomponenten konnen wir Da-tenflussnetze bilden. Die Kanale lassen sich auch einfach als Kommunikationsver-bindungen auffassen, uber die Strome von Daten fließen. Kanale sind dann in jedemSystemablauf Identifikatoren fur Strome. Dies haben wir bereits im Beispiel am Endedes vorangegangenen Kapitels erlautert.

Datenflussdiagramme entsprechen fast direkt den oben besprochenen Graphen zurDarstellung der Systemarchitektur.

Beispiel 4.1: Alternating Bit ProtokollDie Einfuhrung zum Alternating Bit Protokoll war im Abschnitt 1.5 gegeben. Wir

114 18. Marz 2014


betrachten die vier Komponenten eines Systems in Abb. 4.4. Die parallele Kompo-sition der vier Komponenten Sender, Receiver, Medium1 und Medium2 liefert durchVerbindung der entsprechenden Ein- und Ausgabekanale das Datenflussnetz

Sender⊗ Receiver⊗Medium1⊗Medium2

das in Abb. 4.5 dargestellt ist. Durch die parallele Komposition werden gleich be-nannte Ein- und Ausgabekanale miteinander verschalten.

Sender Medium2Medium1Receiver

x c4 c2 c1 c3

c1 c3 y c2 c4

Abb. 4.4.: Vier Komponenten und ihre Kanale

Sender Medium2Medium1Receiver

x c4 c2 c1 c3

c1 c3 y c2 c4

Abb. 4.5.: Datenflussnetz der verschalteten, komponierten Komponenten aus Abb. 4.4

Etwas ubersichtlicher als in Abb. 4.5 wird das Datenflussnetz durch eine etwas ge-schicktere Anordnung der Knoten wie in Abb. 4.6 dargestellt. 2

18. Marz 2014 115


Sender

Medium2

Medium1

Receiverx

c4

c2

c3

c1

y

Abb. 4.6.: Datenflussnetz aus Abb. 4.5 in ubersichtlicher Form

Datenflussnetze konnen auch durch Deklarationen ihrer Kanale textuell dargestelltwerden. Fur obiges Beispiel erhalten wir folgende Darstellung:

(y, c3) = Receiver(c2),(c2) = Medium(c1),(c4) = Medium(c3),(c1) = Sender(x, c4),

Dies entspricht genau der bereits behandelten Konzeption der rekursiven Dekla-ration von Stromen durch verschrankt rekursive Gleichungssysteme. Damit habenwir zwei Moglichkeiten die Komposition von Datenflussknoten zu beschreiben: Gra-phisch durch ein Datenflussdiagramm oder mathematisch durch ein System rekur-siver Gleichungen fur Datenstrome.

4.2.2. Komponenten von Datenflussnetzen

Wir betrachten Systeme und Komponenten, deren Verhalten durch Abbildungenzwischen Datenstromen oder genauer zwischen Belegungen von Kanalen durch Da-tenstrome darstellbar ist. Sei C eine Menge typisierter Kanale.

Mit ~C bezeichnen wir die Menge der Belegungen der Kanale in C, d.h. die Mengeder Abbildungen:

x : C→ ∪ {Mω : M eine der Tragermenge zu den betrachteten Sorten }

wobei fur jeden Kanal c ∈ C der Sorte T der Wert x(c) stets ein Strom von Elementender Sorte T ist.

Eine Abbildung zwischen Belegungen von Kanalen durch Strome ist dann gegebendurch die Funktion

f :~I→ ~O

wobei I und O Mengen von Kanalen bezeichnen. I steht fur die Menge der Eingabe-kanale , O fur die Menge der Ausgabekanale.

116 18. Marz 2014


Ist die Abbildung f prafixmonoton so sprechen wir von einer (deterministischen)datenstromverarbeitenden Funktion. Die Funktion beschreibt das Schnittstellenver-halten einer deterministischen Datenflusskomponente.

4.2.3. Parallele Komposition

Nun zeigen wir, wie wir aus gegebenen stromverarbeitenden Funktionen eine Funk-tion durch Zusammensetzen, durch parallele Komposition, erhalten.

Sind O1 und O2 disjunkte Mengen von Ausgabekanalen und sind

fk :~Ik → ~Ok mit k = 1, 2

stromverarbeitende Funktionen, so definieren wir die parallele Komposition mit Ruck-kopplung parallele

Komposition

Ruckkopp-lung

f1 ⊗ f2

wie folgt. Zunachst definieren wir die Ein/Ausgabekanale

I = (I1 ∪ I2) \ (O1 ∪O2) und O = (O1 ∪O2) \ (I1 ∪ I2)

des zusammengesetzten Systems f. Abb. 4.7 zeigt die Komposition graphisch. DieMenge

L = (I1 ∪ I2) ∩ (O1 ∪O2)

nennen wir die Menge der internen Kanale des durch Komposition entstehendenSystems.Das Verhalten f = f1 ⊗ f2 ist gegeben durch die Funktion:

f1 ⊗ f2 :~I→ ~O

Fur die Eingabe x ∈~I definieren wir

(f1 ⊗ f2)(x) = y

wobei y ∈ ~O, y = z|O, und die Belegung z ∈ ~C der Kanale in

C = O1 ∪O2 ∪ I1 ∪ I2

der kleinste Fixpunkt der folgenden Gleichungen

z|I1∪ I2 = x

f1(z|I1) = z|O1

f2(z|I2) = z|O2

sei. Dabei bezeichnet z|C′ die Restriktion (Einschrankung) der Belegung z auf dieTeilmenge C′ ⊆ C. Man beachte, dass aufgrund der Monotonie der Funktionen f1und f2 Fixpunkte existieren und der kleinste Fixpunkt eindeutig definiert ist.

18. Marz 2014 117


f

f1 f2

O1 \ (I1 U I2) O2 \ (I1 U I2)

I1 \ (O1 U O2) I2 \ (O1 U O2)

I1 ∩ (O1 U O2) I2 ∩ (O1 U O2)

Abb. 4.7.: Graphische Darstellung der Komposition f = f1 ⊗ f2

4.2.4. Nichtdeterministische Komponenten

Eine nicht deterministische Komponente wird durch eine Menge von stromverarbei-tenden Funktionen

F ⊆ {f :~I→ ~O}

dargestellt. Die Funktionen stellen die unterschiedlichen Verhaltensweisen der Kom-ponente dar. Die Komposition von Mengen von Funktionen erfolgt dabei punktweise:

F1 ⊗ F2 = {f1 ⊗ f2 : f1 ∈ F1 ∧ f2 ∈ F2}

Damit konnen wir auch das Verhalten nichtdeterministischer Komponenten undauch von Netzen mit nichtdeterministischen Komponenten beschreiben.

4.3. Kommunikationsnetze

Durch die Dekomposition stromverarbeitender Funktionen in Kommunikationsnetzeerhalten wir eine modulare Darstellung stromverarbeitender Funktionen. Es entste-hen hierarchische Netze von Datenflussknoten.

Ein Datenflussgraph ist ein gerichteter Graph mit markierten Kanten und Knoten.Gewisse Kanten brauchen keinen Ursprung im Inneren des Systems zu haben undwerden deshalb Eingangskanten genannt, andere Kanten haben kein Ziel im Innerendes Systems und heißen deshalb Ausgangskanten. Jede Kante hat hochstens einenUrsprung, kann jedoch viele Ziele haben. Jede Komponente eines Netzes wird selbstwieder im Sinne der hierarchischen Dekomposition durch ein Netz beschrieben, oderes wird ihr Verhalten als Stromverarbeitende Funktion beschrieben.

118 18. Marz 2014


Durch Datenflussnetze konnen wir auch parallele Berechnungen (verteilte Algo-rithmen) beschreiben.

4.3.1. Algorithmen als Datenflussnetze

In diesem Abschnitt zeigen wir ein elementares Beispiel fur die Darstellung einesAlgorithmus als Datenflussnetz.

Beispiel 4.2: Hammings Sequenz berechnet durch DatenflussgraphHammings Sequenz Problem wurde von Edsger Dijkstra bekannt gemacht (vgl.[DDH72]). Es handelt sich um folgende Aufgabe: Erzeuge einen Strom von Zah-len, der in aufsteigender Ordnung genau die Zahlen aus der Menge

{2i ∗ 3j ∗ 5k : i, j, k ∈ N}

enthalt. Dieser Strom heißt Hammingsequenz und seine erste Elemente ergeben sichwie folgt:

1

2 = 2

3 = 3

4 = 2 ∗ 2

5 = 5

6 = 2 ∗ 3

8 = 2 ∗ 2 ∗ 2

9 = 3 ∗ 3

10 = 2 ∗ 5

12 = 2 ∗ 2 ∗ 3

. . .

Wir arbeiten mit folgenden Komponenten als Hilfsfunktionen zur Erzeugung derHammingsequenz:

fct streammult = (n: Nat, s: Stream Nat) Stream Nat:(n× first(s)) & streammult (n, rest(s))

fct omerge = (s1, s2: Stream Nat) Stream Nat:if first(s1) ≤ first(s2) then first(s1) & omerge(rest(s1), s2)

else first(s2) & omerge(s1, rest(s2)) fi

18. Marz 2014 119


Mit Hilfe dieser Funktionen definieren wir das Datenflussnetz in Abb 4.8 durchfolgende Gleichungen:

Stream Nat s1 = streammult(5, 1 & s1)Stream Nat s2 = omerge(streammult(3, 1 & s2), s1)Stream Nat s3 = omerge(streammult(2, 1 & s3), 1 & s2)

Wir erhalten durch einfaches Rechnen

s1 = streammult(5, 1 & s1)= (5× 1) & streammult(5, s1)= 5 & streammult(5, s1)

Auf solche Weise erhalten wir fur s1 einen unendlichen Strom bestehend aus dennaturlichen Zahlen der Form 5k, k ∈ N+. Dies ergibt den Strom 〈5, 25, 125, . . .〉.Weiter erhalten wir den Strom

s2 = omerge(streammult(3, 1 & s2), s1)= omerge((3× 1) & streammult(3, s2), 〈5, 25, 125, . . .〉) // Def. von streammult= omerge(3 & streammult(3, s2), 〈5, 25, 125, 5, . . .〉) // Def. von streammult= 3 & omerge(streammult(3, s2), 〈5, 25, 125, 5, . . .〉) // Def. von omerge, 3 ≤ 5= 3 & 5 & omerge(streammult(3, s2), 〈5, 25, 125, . . .〉) // Def. von omerge, 5 ≤ 9. . .= 〈3, 5, 9, 15, 25, 27, 45, 75, 81, 125, . . .〉

s2 enthalte alle Zahlen, die nur die Vielfachen 3 und 5 als Primfaktoren enthalten.

s3 = omerge(streammult(2, 1 & s3), 1 & s2)// Def. von streammult= omerge(2 & streammult(2, s3), 〈1, 3, 5, 9, 15, 25, 27, 45, 75, 81, 125, . . .〉)// Def. von omerge 1 ≤ 2= 1 & omerge(2 & streammult(2, s3), 〈3, 5, 9, 15, 25, 27, 45, 75, 81, 125, . . .〉)// Def. von omerge 2 ≤ 3= 1 & 2 &omerge(streammult(2, s3), 〈3, 5, 9, 15, 25, 27, 45, 75, 81, 125, . . .〉). . .= 〈1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, . . .〉

So wird der Strom s3 gleich der Hammingsequenz gebildet, die aus der aufsteigendenFolge aller Zahlen besteht, die nur 2, 3 oder 5 als Primfaktoren besitzen. Dieses Sys-tem von Deklarationen fur die Strome s1, s2 und s3 (Gleichungen) konnen wir, wiein Abb. 4.8 gegeben, durch ein Datenflussnetz darstellen. Im Datenflussdiagrammtreten neben den Kanten fur die Strome s1, s2 und s3 weitere Strome auf, die denWerten der Teilausdrucke auf den rechten Seiten der definierenden Gleichungen ent-sprechen. 2

120 18. Marz 2014


λ x. 1 & x

omerge

s1

λ x. streammult(5,x)

λ x. 1 & x


omerge

λ x. 1 & x


s2

s3

λ x. 1 & x

Abb. 4.8.: Datenflussnetz zur Berechnung der Hammingsequenz

Wir konnen die Gleichungen im Beispiel noch weiter aufbrechen, so dass fur jedeKante im Netz genau eine Stromgleichung angegeben wird.

18. Marz 2014 121


Wie das Sieb des Erathostenes ist Hammings Sequenz besonders elegant mitstromverarbeitenden Funktionen zu behandeln, da es sich in beiden Fallen um dieAufgabe handelt, eine unendliche Folge von Zahlen zu generieren. Generell konnenwir das Prinzip der rekursiven Aufzahlung elegant durch Strome erfassen.

4.3.2. Kantenfuhrung in Kommunikationsnetzen

In Datenflussdiagrammen treten oft Knoten der in Abb. 4.9 angegebenen Formauf, wo zwei Strome zusammengefuhrt werden. Diese Knoten mussen in nichtde-terministisches Mischen ubersetzt werden. Sie entsprechen somit den in Abb. 4.10angegebenen Knoten. Mischknoten sind in der Regel hochgradig nichtdeterminis-tisch. Im Zusammenhang mit Ruckkopplungsschleifen konnen subtile Probleme mitMischkomponenten auftreten, die mit der

”Fairness“ des Mischens zu tun haben.

Wir kommen darauf zuruck.

Abb. 4.9.: Zusammenfuhrung im Datenflussdiagramm

merge

c1 c2

c3

Abb. 4.10.: Mischknoten

Man kann die Zusammenfuhrung von Kanten auch in gesteuertes Mischen uber-setzen. Dabei werden zwei Strome nicht nichtdeterministisch gemischt, sondern eswird uber einen Booleschen Strom gesteuert, in welcher Reihenfolge die Elementegemischt werden – ein entsprechender Datenflussnetz ist in Abb. 4.11 gegeben.

Das uber einen Booleschen Strom gesteuerte Mischen wird durch folgende Funk-tion beschrieben.

122 18. Marz 2014


fct inswitch = (c : Stream Bool, s1, s2 : Stream α)Stream α :if first(c) then first(s1) & inswitch(rest(c), rest(s1), s2)

else first(s2) & inswitch(rest(c), s1, rest(s2))fi

inswitch

Abb. 4.11.: Gesteuertes Mischen

Aus dem Gesagten ergibt sich, dass wechselseitige Kommunikation zwischen par-allel ablaufenden Einheiten durch verschrankte Rekursion auf Stromen modelliertwird. Die Markierung der Kanten in einem Datenflussnetz verstehen wir als Identi-fikatoren fur Strome, die Markierung der Funktionssymbole als stromverarbeitendeFunktionen.

4.3.3. Systeme als Kommunikationsnetze

Fur gegebene stromverarbeitende Funktionen fi mit ni Eingangen und mi Ausgangenbetrachten wir folgende Kompositionsformen, die der Zusammensetzung der Kom-ponenten in Netzen entspricht.

Beispiel 4.3: Erzeuger-Verbraucher-Problem als DatenflussnetzUnter dem

”Erzeuger-Verbraucher-Problem“ verstehen wir folgendes System. Ge-

nau zwei Prozesse, die in der Regel nicht immer gleich schnell Ergebnisse erzeugen,kommunizieren uber einen gemeinsamen Speicherbereich begrenzter Grosse (einensogenannten Puffer), auf den entweder lesend oder schreibend zugegriffen werdenkann. Es gelten folgende Bedingungen:

� der Erzeuger darf nur soviel Elemente schreiben, wie in der Speicher umfasst,

� der Verbraucher darf nur lesen, wenn vorher geschrieben wurde.

Dabei soll sichergestellt werden, dass jedes in den Pufferspeicher geschriebene Daten-element genau einmal gelesen wird. Die schematische Beschreibung des

”Erzeuger-

Verbraucher-Systems“ ist in Abb. 4.12 gegeben.

18. Marz 2014 123


Das einfachste Datenflussnetz fur das”Erzeuger-Verbraucher-Problem“ mit der

Speicherbereichgroße n kann man wie auf der Abb. 4.13 gezeigt darstellen: Zunachstbekommt der Erzeuger die Speicherbereichgrosse n als den Strom x0 = n & 〈〉 unddann startet die Kommunikation zwischen Erzeuger und Verbraucher. Der Eingabe-kanal x bezeichnet mit welchem Wert die Erzeugung gestartet wird. Wir betrachtenden Fall, bei dem der Puffer unbegrenzt ist.

…

Leserposition(Verbraucher)

Schreibeposition(Erzeuger)

Abb. 4.12.: Das Schema fur Erzeuger/Verbraucherproblem

product consumx0

s1

s2

Abb. 4.13.: Datenflussnetz fur Erzeuger/Verbraucherproblem

fct product = (x, s2 : Stream Nat,b : Bool)Stream Nat :if b then pro(first(x)) & product(rest(x),s2, false)

else pro(first(s2)) & product(rest(x),rest(s2), false)fi

fct pro = (x: Nat) Nat: x − 1

124 18. Marz 2014


fct consum = (s1: Stream Nat) Stream Nat:if isempty(s1) then empty

else consum1(first(s1)) & consum(rest(s1))fi

fct con = (y: Nat) Nat: y + 1

Die folgenden rekursiven Gleichungen fur Strome definieren ein Datenflussprogrammfur das Erzeuger/Verbraucher-Problem, die Mischfunktion merge ist im Abschnitt3.7 gegeben:

stream s1= product(x, s2, true),stream s2= consum(s1).

Wieder geben die Gleichungen die graphische Darstellung wieder. 2

Das Beispiel illustriert die Modellierung von Systemen durch Kommunikationsnetze.

4.3.4. Berechnung von Funktionen durch Datenflussnetze

Durch Datenflussnetze lassen sich auch Funktionen berechnen, in denen wir Algo-rithmen durch Datenflußnetze beschreiben.

Beispiel 4.4: Fakultat als DatenflussnetzBetrachten jetzt ein zu dem Beispiel Erzeuger/Verbraucher ahnliches, aber kompli-zierteres Problem: Ein Datenflussprogramm, das die Fakultatsfunktion berechnet.

Die folgenden rekursiven Gleichungen fur Strome definieren dieses Datenflusspro-gramm

stream s1 = merge(x0, s5), stream s2 = nfilter(s3, s1),stream s3 = C∗(s1), stream s4 = pfilter(s3, s1),stream s5 = pro∗(s2), stream s6 = merge(y0, s8),stream s7 = nfilter(s3, s6) stream s8 = con∗(s2, s7),stream s9 = nfilter(s3, s1)

wobei wir folgende Hilfsfunktionen zur Beschreibung der Komponenten verwenden.Die Filterfunktionen beschreiben das Verhalten des Switch-Knoten. Deshalb konnen

wir den Switch-Knoten (Black-Box-View sehe Abb. 4.14) als ein Netz von Nfilter-und Pfilter-Knoten darstellen (sehe Abb. 4.15).

Die Funktion pfilter(c: Stream Bool, s: Stream α) bewirkt folgendes: Wenn das ersteElement des Stroms c true ist, dann wird das erste Element vom Eingangsstromzum aktuellen (ersten) Element des Ergebnissstroms s und dann wird die gleicheFunktion pfilter (positiven Filter) zum Rest der Strome c und s verwendet, wennaber first(c) = false, dann wird first(s) ignoriert und die Funktion pfilter wird fur denRest der Strome c und s verwendet.

18. Marz 2014 125


switch

Abb. 4.14.: Switch-Knoten: Black-Box-View

pfilter nfilter

s1 / s6 s3

s2 / s7s4 / s9

Abb. 4.15.: Switch-Knoten: Glass-Box-View

fct pfilter = (c: Stream Bool, s: Stream α) Stream α:if isempty(c) then empty

else if first(c) then first(s) & pfilter(rest(c), rest(s))else pfilter(rest(c), rest(s)) fi fi

Die Funktion nfilter (negativer Filter) ist sehr ahnlich zur Funktion pfilter, der Un-terschied liegt darin, dass first(s) ignoriert wird, wenn first(c) = true:

fct nfilter = (c: Stream Bool, s: Stream α) Stream α:if isempty(c) then empty

else if first(c) then nfilter(rest(c), rest(s))else first(s) & nfilter(rest(c), rest(s))

fifi

Fur eine beliebige Funktionen f : α → α erhalten wir mit f∗ eine Erweiterung aufStrome:

126 18. Marz 2014

4.4. Kompositionsformen

fct f∗ = (s: Stream α) Stream α:if isempty(s) then empty

else f(first(s)) & f∗(rest(s))fi

Auf solche Weise sind die Funktionen C∗, pro∗ und con∗ definiert. Funktion C∗

liefert den Wahrheitswert true, wenn die Berechnung der Fakultat fur die aktuelleZahl beendet ist.

fct C∗ = (s: Stream Nat) Stream Bool:if isempty(s) then empty

else C(first(s)) & C∗(rest(s))fi

fct C = (n: Nat) Bool: if n = 0 then true else false fi

fct pro∗ = (s: Stream Nat) Stream Nat:if isempty(s) then empty

else pro(first(s)) & pro∗(rest(s)) fi

fct pro = (x, y: Nat) Nat: x + y

fct con∗ = (s1, s2: Stream Nat) Stream Nat:if isempty(s1) ∧ isempty(s2)

then emptyelse con(first(s1), first(s2)) & con∗(rest(s1), rest(s2))

fi

fct con = (x, y: Nat) Nat: x ∗ y

Jetzt konnen wir das obige Gleichungsystem in graphischer Form wiedergeben, wiein der Abb. 4.16 dargestellt. In den Datenflussnetz gelten folgende Gesetze: Aus

x0 = 〈n1, n2, n3, . . .〉 und y0 = 〈1, 1, 1, . . .〉

folgt

s4 = 〈true, true, true, . . .〉 und s9 = 〈n1!, n2!, n3!, . . .〉,

wobei jedes Element des Stroms das Ende der Fakultaberechnung fur die aktuelleZahl signalisiert.


Bisher haben wir nur eine allgemeine, sehr machtige Form der Komposition auf Kom-ponenten beschrieben. Nun betrachten wir eine Reihe weiterer elementaren Kompo-sitionsformen.

18. Marz 2014 127


switch switch

C*

pro* con*

x0

s6

y0

s7

s3

s2s4

s1

s1

s9

s5 s8

Abb. 4.16.: Datenflussnetz fur Fakultat-Problem

4.4.1. Parallele Komposition ohne Ruckkopplung

Die parallele, unabhangige Komposition zweier stromverarbeitenden Komponentenmit disjunkten Mengen von Ausgabekanalen ist sehr einfach. Seien die Komponenten

f1 :~I1 → ~O1

f2 :~I2 → ~O2

gegeben und gelte O1 ∩O2 = ∅. Wir definieren die Funktion

f1‖f2 :~I→ ~O mit I = I1 ∪ I2 und O = O1 ∪O2

durch

(f1‖f2).x = (f1.(x|I1))⊕ (f2.(x|I2))

Dabei bezeichnet ⊕ das Konkatenieren von Tupeln von Stromen. Die parallele Kom-position ist in Abb. 4.17 graphisch dargestellt. Dabei bezeichnen wir durch x|I furParallele

Komposition I ⊆ C und x ∈ ~C die Belegung in~I, die durch die Einschrankung von x auf die Kanalein I entsteht.

128 18. Marz 2014


f1

f2…

……

…

Abb. 4.17.: Parallele Komposition

4.4.2. Ruckkopplung

Die Ruckkopplung (engl. Feedback) eines Ausgabekanals auf eine Eingabekanals einerKomponente definieren wir wie folgt. Sei die stromverarbeitende Funktion Ruck-

kopplungFeedbackf :~I→ ~O

gegeben und seien r ∈ I, sowie p ∈ O Kanale gleicher Sorte. Wir definieren dieFunktion

[r← p : f] : ~I′ → ~O

mit I′ = I\{r}, die durch Ruckkopplung der Ausgabe auf Ausgabekanal p auf denEingabekanal r entsteht, wie folgt

[r← p : f].x = fix λ y : f(x⊕ {r 7→ y.p})

Die Ausgabe der Funktion, die durch Ruckkopplung entsteht, entspricht also derAusgabe der Funktion f auf die Eingabe x, wobei der Kanal r den kleinsten Da-tenstrom (im Sinne der Prafixmonotonie) enthalt, der die Ruckkopplungsgleichungerfullt. Mit Hilfe der beiden Operatoren konnen wir beliebige Datenflussnetze auf-bauen. Es existieren auch graphische Veranschaulichungen fur die Operatoren. Abb.4.18 stellt die Ruckkopplung graphisch dar.

4.4.3. Sequentielle Komposition

Sei O1 = I2, dann ist f1◦f2 eine stromverarbeitende Funktion mit Eingangskanalen I1

und Ausgangskanalen O2. Die sequentielle Komposition ist in Abb. 4.19 dargestellt.Es gilt: Sequentielle

Komposition

(f1 ◦ f2)(x) = f2(f1(x))

18. Marz 2014 129


μf1

……

r

yx

p……

Abb. 4.18.: Ruckkopplung

f1 f2 ………

Abb. 4.19.: Sequentielle Komposition

Durch diese Kompositionsformen und durch eine Reihe einfacher Komponenten furdas Kopieren und Permutieren von Eingangsstromen lassen sich alle Datenfluss-netze durch die parallele und sequentielle Komposition der Komponenten und eineReihe von Ruckkopplungen darstellen. Ebenso konnen wir sie durch ein rekursivesGleichungssystem fur die Strome darstellen.

Wir konnen aber auch nur den universellen Operator ⊗ einfuhren, der die paralleleKomposition und die Ruckkopplung kombiniert.

Mit Hilfe der eingefuhrten Operatoren konnen wir verteilte Systeme durch Termegleichsam als Programme in einer Datenflusssprache darstellen. Daneben existierteine graphische Darstellung durch Datenflussnetze. Beide Darstellungen sind sche-matisch ineinander uberfuhrbar. Die Bedeutung eines verteilten Systems laßt sichdurch die Definition der Operatoren in Form einer stromverarbeitenden Funktionangeben.

Beispiel 4.5: SchedulerWir spezifizieren hier ein Scheduler fur folgendes System: Das System besteht auseinem Scheduler und zwei Anwendungen. Der Scheduler hat nur einen Eingang undeinen Ausgang. Er erhalt die Auftrage von den Anwendungen und bearbeitet diesewie folgt:

� Wenn keine der Anwendungen aktiv ist und der Auftrag von der Anwendungi kommt (i ∈ {1, 2}), startet der Scheduler die Anwendung i.

130 18. Marz 2014


� Wenn die Anwendung i (i ∈ {1, 2}) aktiv ist und der Auftrag von der anderenAnwendung k (k ∈ {1, 2}, i 6= k) kommt, wird die Anwendung i

”preempted“,

das heißt unterbrochen, dann startet der Scheduler die Anwendung k.

� Wenn die Anwendung i (i ∈ {1, 2}) als aktiv bezeichnet ist und von dieser dieBestatigung kommt, dass die Arbeit schon beendet ist (die Anwendung i wirdpassiv), entweder startet der Scheduler die Anwendung k (k ∈ {1, 2}, i 6= k) –wenn die

”preempted“ war, oder wartet auf die nachsten Auftrage.

Da der Scheduler nur einen Eingang und nur einen Ausgang hat, benutzen wirnoch zwei Datenflusskomponenten, Merge und Demerge (die Definitionen fur dieentsprechenden stromverarbeitenden Funktionen haben wir in den Beispielen obengegeben). Wir stellen dieses verteiltes System wie in der Abb 4.20 dar. Seien dieMengen Request und Action wie folgt definiert:

Request = Request1 ∪ Request2Request1 = {ready1, done1}Request2 = {ready2, done2}

Action = Action1 ∪ Action2Action1 = {do1, preempt1}Action2 = {do2, preempt2}

Wir definieren eine stromverarbeitende Funktion mit 3 Argumenten – Eingabestromund zwei Paramethern, pr und activ, die den aktuellen Zustand beschreiben werden:

pr,activ : {0, 1, 2}

Wir betrachtet hier keine Fehlersituationen.

pr = 0 keine Anwendung ist preempted (unterbrochen)pr = i i-te Anwendung ist preempted (unterbrochen), i ∈ {1, 2}activ = 0 alle Anwendungen sind passivactiv = i i-te Anwendung ist aktiv, i ∈ {1, 2}

Nur 5 Kombinationen sind moglich:

pr = 0 ∧ activ = 0,pr = 0 ∧ activ = 1,pr = 0 ∧ activ = 2,pr = 1 ∧ activ = 2,pr = 2 ∧ activ = 1.

18. Marz 2014 131


Scheduler

pr: {0,1,2}activ: {0,1,2}

…

x1 : T1

xn : Tn

r: Request Merge

Demergea: Action

Anwendung1

Anwendung2

r1: Request1

r2: Request2

a1: Action1a2: Action2

Abb. 4.20.: Verteiltes System mit Scheduler

Die Gultigkeit der Zusicherungen pr = 1 ∧ activ = 1 und pr = 2 ∧ activ = 2 istausgeschlossen, weil eine Anwendung preempted und nicht gleichzeitig aktiv seindarf.

Die Gultigleit der Zusicherungen pr = 1 ∧ activ = 0 und pr = 2 ∧ activ = 2 sindunmoglich, weil eine Anwendung sofort gestartet werden sollte, wenn die Ressourcenfrei sind.

fct scheduler = (r: Stream Request, pr, activ: {0, 1, 2}) Stream Action:case (pr, active) of

(0, 0) ⇒ { first(r) = ready1 ∨ first(r) = ready2 }if first(r) = ready1 then do1 & scheduler(rest(r), 0, 1)

else do2 & scheduler(rest(r), 0, 2) fi| (0, 1) ⇒ { first(r) = ready2 ∨ first(r) = done1 }

if first(r) = ready2 then preempt1 & do2 & scheduler(rest(r), 1, 2)else scheduler(rest(r), 0, 0) fi

| (0, 2) ⇒ { first(r) = ready1 ∨ first(r) = done2 }if first(r) = ready1 then preempt2 & do1 & scheduler(rest(r), 2, 1)

else scheduler(rest(r), 0, 0) fi| (1, 2) ⇒ (first(r) = done2 ⇒ do1 & scheduler(rest(r), 0, 1) )| (2, 1) ⇒ (first(r) = done1 ⇒ do2 & scheduler(rest(r), 0, 2) )

end;

Nun definieren wir den Scheduler als eine Zustandsmaschine. Da wir 5 moglicheKombinationen von den Parametern pr und activ haben, definieren wir die Zustands-maschine mit 5 entsprechenden Zustanden h1, . . . , h5. Stellen wir die Zustandsma-schine als ein Zustandsubergangsdiagramm wie in der Abb. 4.21 dar.

132 18. Marz 2014


h2pr = 0

activ = 1

h4pr = 1

activ = 2

h5pr = 2

activ = 1

h3pr = 0

activ = 2

h1pr = 0

activ = 0

{pr = 0, activ = 0}ready1 / do1 {pr = 0, activ = 1}

pr = 0, activ = 0 {pr = 0, activ = 0}ready2 / do2 {pr = 0, activ = 2}

{pr = 0, activ = 1}done1 / –{pr = 0, activ = 0}

{pr = 0, activ = 2}done2 / –{pr = 0, activ = 0}

{pr = 0, activ = 1}ready2 / preempt1 & do2 {pr = 1, activ = 2}

{pr = 1, activ = 2}done2 / do1 {pr = 0, activ = 1}

{pr = 2, activ = 1}done1 / do2 {pr = 0, activ = 2}

{pr = 0, activ = 2}ready1 / preempt2 & do1 {pr = 2, activ = 1}

Abb. 4.21.: Scheduler: Zustandsubergangsdiagramm

Wir zeigen nun, wie das Ubergangsschema entsteht.

1. Von der stromverarbeitenden Funktion zur Zustandsmaschine.Wir definieren eine Zustandsmaschine

∆: Σ × Request → Σ × Stream Action∆(h, r) = (h′, a)

wobei h, h′ ∈ State, r ∈ Request, a ∈ Stream Action und folgende Eigenschaftengelten:

r = h(〈a〉)h(r & x) = ah′(x) (x ∈ Stream Request)

Da es 5 mogliche Kombinationen von den Parametern pr und activ gibt, be-notigen wir 5 Hilfsfunktionen h1, . . . , h5:

fct h1 = (r: Stream Request) Stream Action:{ first(r) = ready1 oder first(r) = ready2 }

if first(r) = ready1 then do1 & h2(rest(r))else do2 & h3(rest(r)) fi;

18. Marz 2014 133


fct h2 = (r: Stream Request) Stream Action:{ first(r) = ready2 oder first(r) = done1 }

if first(r) = ready2 then preempt1 & do2 & h4(rest(r))else h1(rest(r)) fi;

fct h3 = (r: Stream Request) Stream Action:{ first(r) = ready1 oder first(r) = done2 }

if first(r) = ready1 then preempt2 & do1 & h5(rest(r))else h1(rest(r)) fi;

fct h4 = (r: Stream Request) Stream Action:(first(r) = done2 ⇒ do1 & h2(rest(r)))

fct h5 = (r: Stream Request) Stream Action:(first(r) = done1 ⇒ do2 & h3(rest(r)))

Es ist leicht zu sehen, dass folgende Gleichungen gelten:

∆(h1, ready1) = (h2, 〈do1〉),∆(h1, ready2) = (h3, 〈do2〉),∆(h2, ready2) = (h4, 〈preempt1, do2〉),∆(h2, done1) = (h1, 〈〉),∆(h3, ready1) = (h5, 〈preempt2, do1〉),∆(h3, done2) = (h1, 〈〉),∆(h4, done2) = (h2, 〈do1〉) und∆(h5, done1) = (h3, 〈do2〉).

Dies beschreibt eindeutig die Ubergange der Zustandsmaschine aus Abb. 4.21.

2. Von der Zustandsmaschine zur stromverarbeitenden Funktion.Wir definieren eine stromverarbeitende Funktion

f: State → (Stream Request → Stream Action)

so dass fur jeden Zustand σ ∈ {h1, . . . , h5}

fσ: Stream Request → Stream Action

spezifiziert durch (sei i ∈ Request, x ∈ Stream Action) die Gleichung

fσ(i & x) = o & fσ′(x)

134 18. Marz 2014

4.5. Pradikative Spezifikation von Kommunikationsanweisungen

wobei der Zustand σ′ und die Ausgabe o durch die folgenden Gleichungenfestgelegt sind:

(σ’, o) = ∆(σ, i):

fh1 = (r: Stream Request) Stream Action:{ first(r) = ready1 oder first(r) = ready2 }

if first(r) = ready1 then do1 & fh2(rest(r))else do2 & fh3(rest(r)) fi;

fh2 = (r: Stream Request) Stream Action:{ first(r) = ready2 oder first(r) = done1 }

if first(r) = ready2 then preempt1 & do2 & fh4(rest(r))else fh1(rest(r)) fi;

fh3 = (r: Stream Request) Stream Action:{ first(r) = ready1 oder first(r) = done2 }

if first(r) = ready1 then preempt2 & do1 & fh5(rest(r))else fh1(rest(r)) fi;

fh4 = (r: Stream Request) Stream Action:(first(r) = done2 ⇒ do1 & fh2(rest(r)))

fh5 = (r: Stream Request) Stream Action:(first(r) = done1 ⇒ do2 & fh3(rest(r)))

Es ist einfach zu sehen, dass die Funktion f gleich der Funktion scheduler ist:Wenn wir den Zustand durch die Parametern pr und activ ersetzen, die diesenZustand eindeutig beschreiben, bekommen wir die Funktion scheduler.

2

Der Ubergang zwischen stromverarbeitenden Funktionen und Zustandsmaschinenkann in der einen Richtung als Schnittstellenabstraktion und in der anderen Rich-tung als Implementierungsschritt verstanden werden.

4.5. Pradikative Spezifikation von

Kommunikationsanweisungen

In der pradikativen Spezifikation zuweisungsorientierter Programme konnen wir ne-ben den in sequentiellen Programmen behandelten Anweisungen auch Kommunika-tionsaktionen als Anweisungen betrachten. Dazu fuhren wir zwei Arten von Kanalenfur eine Anweisung ein:

18. Marz 2014 135


� Eingabekanale,

� Ausgabekanale.

Jeder Kanal, bezeichnet durch einen Identifikator, ist entweder ein Eingabekanaloder ein Ausgabekanal.

Uber Eingabekanale C konnen wir Nachrichten empfangen. Wir schreiben

e ? v

fur die Anweisung, die dem Empfang einer Nachricht uber den Kanal e bewerkstel-ligt, wobei dieser empfangene Wert in der Variable v gespeichert wird. v ist dabeieine Variable der gleichen Sorte wie die Nachrichten im Kanal e.

Uber Ausgabekanale c konnen Werte ausgegeben werden. Wir schreiben

c ! E

um auszudrucken, dass der Wert des Ausdrucks E auf dem Kanal c ausgegeben wird.Reichern wir die Sprache der bewachten Anweisungen um diese Anweisungen an, sokonnen wir Programme schreiben, die uber Kanale kommunizieren.

Beispiel 4.6: Programm mit Kanal-KommunikationEin einfaches Beispiel ist eine Prioritatsschlange fur Zahlen. Das Programm liestZahlen ein und gibt auf Anforderung die großte gespeicherte Zahl wieder aus.

Wir verwenden zwei Kanale

r : Chan Nat | { R©}p : Chan Nat | { error }

Wir wahlen folgendes Programm:

proc pq ={ v : var Nat | { R©}

q : var Seq Natdo true then r ? v;

if v = R© ∧ q 6= empty then p ! fisrt(q); q := rest(q)[] v = R© ∧ q = empty then p ! error[] v 6= R© then q := insert(q, v)fi

od }

wobei die Hilfsfunktion insert wie folgt definiert ist:

136 18. Marz 2014


fct insert = (q : Seq Nat, v : Nat):if isempty(q) then 〈v〉elif v ≥ first(q) then 〈v〉 q

else 〈 first(q) 〉 insert(rest(q), v)fi

2

In einer pradikativen Spezifikation verwenden wir fur jeden Kanal c zwei Variablenc8 und c′ (gesprochen

”c in“ und

”c out“), wobei c8 den Strom auf dem Kanal

vor Ausfuhrung der Anweisung und c′ den Strom nach Ausfuhrung der Anweisungbezeichnet. Jede der Bezeichnungen steht fur eine Variable fur einen Datenstrom.

Die Eingabeanweisung (sei r ein Eingabekanal der Sorte M, v eine Programmva- Eingabe-anweisungriable der Sorte M)

r ? v (lies den Wert von v vom Eingabekanal r)

entspricht der folgenden pradikativen Spezifikation

(r′ = rest(r8) ∧ v′ = first(r8)) ∨ r′ = 〈〉

Falls r8 der leere Strom ist, ist der Ausdruck aquivalent zu true, also zu”Chaos“. Hier

konnen wir auch durch eine spezielle Kontrollvariable anzeigen, dass das Programmnicht terminiert.

Die Ausgabeanweisung (sei p Ausgabekanal der Sorte M und E Ausdruck der Sorte Ausgabea-nweisungM):

p ! E (schreibe den Wert von E auf den Kanal p)

entspricht der pradikativen Spezifikation

p′ = p8 〈E8〉Fur Eingabekanale gilt damit stets (d. h. fur jede Anweisung) das Axiom: Axiom fur

Eingabekanale

∃ x ∈ Stream α: r8 = x8 r′

Dieses Gesetz formalisiert den Umstand, dass wir auf Eingabekanale nur Werte lesen(und damit entfernen), aber keine neuen Werte schreiben konnen.

Fur Ausgabekanale gilt stets die Aussage Axiom furAusgabekanale

∃ x ∈ Stream α: p′ = p8 x8

18. Marz 2014 137


Dieses Gesetz formalisiert den Umstand, dass wir auf Ausgabekanalen nur weitereWerte schreiben aber keine geschriebenen Werte entfernen konnen.

Mit Hilfe der obigen Ubersetzung von Ein-/Ausgabe-Anweisungen in pradikativeSpezifikationen lassen sich insbesondere interaktive zuweisungsorientierte Program-me spezifizieren.

Beispiel 4.7: Zuweisungsorientierte Programme mit Ein- und AusgabeSei im Folgenden stets r der Lesekanal, p der Druckkanal.

(1) AufsummierenDas Aufsummieren der bisherigen Eingaben auf Kanal r und Ausgabe ist wiefolgt beschrieben.

p′ = p8 ◦ 〈sum8〉 ∧ 〈sum′〉 = 〈sum8〉 + first(r8) ∧ r′ = rest(r8)

Dies entspricht der Anweisung

p ! sum; r ? v; sum := sum + v

wobei hier die Hilfsvariable v verwendet wird.

(2) Vergleich von Eingaben

(r′ = rest(rest(r8)) ∧ |r8| ≥ 2 ∧first(r8) = first(rest(r8)) ⇒ p′ = p8 〈

”Korrekte Eingabe“〉 ∧

first(r8) 6= first(rest(r8)) ⇒ p′ = p8 〈”Fehlerhafte Eingabe“〉 )

∨ |r8| < 2

Beispielsweise, wird der Strom 〈a, a, b, b, c, c〉 als Eingabe auf dem Kanal rals korrekt angesehen, aber 〈a, b, b, c, c, d〉 nicht.

(3) Vergleich von Eingaben mit Eingabeanforderung, Ausgabe und Bestatigung

|r8| = 0 ⇒ ∃ s: p′ = p8 〈”gib Eingabe“〉 s

|r8| = 1 ⇒∃ s: p′ = p8 〈

”gib Eingabe“〉〈

”bestatige“〉〈first(r8)〉 s ∧ r′ = 〈〉

|r8| ≥ 2 ⇒r′ = rest(rest(r8)) ∧

first(r8) = first(rest(r8)) ⇒p′ = p8 〈


”bestatige“〉〈first(r8)〉〈

”o.k.“〉

first(r8) 6= first(rest(r8)) ⇒p′ = p8 〈


”bestatige“〉〈first(r8)〉〈

”negativ“〉

138 18. Marz 2014


(4) Ausgabe der Eingabe p′ = p8 r8. 2

Achtung: Die adaquate Behandlung der sequentiellen Komposition zuwei-sungsorientierter Programme erzwingt, dass Eingabekanale in beschrankter Weiseals veranderte Werte im Folgezustand (genauer als Teil des Endzustands) behandeltwerden und Ausgabekanale in beschrankter Weise als Eingabe (genauer als Bestand-teil des Anfangszustands) dienen, da aus ihnen die Gesamtausgabe konstruiert wird.

Beispiel 4.8: Programme zu den pradikativen Spezifikationen aus obigen Bei-spielenProgrammbeispiele, die den pradikativen Spezifikationen genugen, die wir oben an-gegeben haben, sind nachfolgend als Programme wiedergegeben.

(1) r ? x; sum := sum + x; p ! sum

(2) r ? x;r ? y;if x = y then p !

”korrekte Eingabe“

else p !”fehlerhafte Eingabe“

fi

(3) p !”gib Eingabe“;

r ? x;p !

”bestatige“;

r ? y;if x = y then p ! x; p !

”o.k.“

else p ! x; p !”negativ“

fi

(4) do true then r ! x; p ? x od

(5) Filter(n)

Abb. 4.22 gibt die Komponente Filter(n) graphisch wieder.

Filter(n)a b

Abb. 4.22.: Die Filterfunktion als Datenflussknoten

Das folgende Programm beschreibt das Verhalten des Datenflussknotens Filter(n).

18. Marz 2014 139


a ? n;do true then a ? v;

if n ? v then nop[] n = v then b ! vfi

od

Die pradikative Spezifikation des Filterknotens ist deutlich einfacher als das entspre-chende anweisungsorientierte Programm:

b′ = b8 filter(first(a),a8)

Eine der Grunde fur die Kurze dieser Spezifikation ist die Verwendung der Hilfs-funktion filter. 2

Die pradikative Spezifikation und die dazugehorigen Programme stellen eine Moglich-keit dar, Datenflussknoten prozedural zu spezifizieren, zu programmieren und somitDatenflussknoten eine Realisierung und eine formale Bedeutung zuzuordnen. DieDatenflussknoten arbeiten zueinander parallel. Grundsatzlich entspricht ein Daten-flussgraph damit einem parallelen Programm.

Beispiel 4.9: Die Warteschlange als Programm mit Ein- und AusgabeWir betrachten das folgende Programm:

d q : var Seq Data := 〈〉; var v : M := R©;do true then x ? v;

if v = R© ∧ q 6= 〈〉 then y ! first(q); q := rest(q)[] v 6= R© then q := q 〈v〉fi

od

(∗)

c

Die pradikative Spezifikation der Anweisung (*) liest sich wie folgt:

x′ = 〈〉∨ [ x′ = rest(x8)

∧ v′ = first(x8)

∧ [ (q8 6= 〈〉 ∧ v8 = R© ∧ y′ = y8 〈first(q)〉 ∧ q′ = rest(q8))

∨ (q8 = 〈〉 ∧ v8 = R© ∧ y′ = y8 ∧ q′ = 〈〉)∨ (v8 6= R© ∧ q′ = q8 〈v′〉 ∧ y′ = y8 ] ]

Durch pradikative Spezifikation konnen kommunizierende Programme mit lokalenZustandsvariablen durch logische Zusicherungen beschrieben werden.

140 18. Marz 2014

4.6. Parallele Komposition zuweisungsorientierter interaktiven Programme

4.6. Parallele Komposition zuweisungsorientierter

interaktiven Programme

Auch wenn die Komponenten durch zuweisungsorientierte interaktive Programmebeschrieben sind, konnen wir die parallele Komposition auf der logischen Ebenevornehmen. Wir zeigen nun auf wie Datenflusskomponenten durch anweisungsorien-tierte Programme beschrieben werden konnen.

4.6.1. Parallele Komposition von Programmen die uber Kanalekommunizieren

Zuweisungsorientierte Programme S1 und S2 mit Interaktionsanweisungen lassen sichohne Schwierigkeiten parallel zusammensetzen, solange die Mengen der in S1 und S2auftretenden Kanale und Programmvariablen disjunkt sind. Wir schreiben dann

S1 ‖ S2

Sind Q1 und Q2 pradikative Spezifikationen des Programms S1 beziehungsweise S2,dann ist

Q1 ∧ Q2

eine pradikative Spezifikation von S1 ‖ S2.Wir geben folgende Prazisierung durch eine pradikative Spezifikation der Ein/Aus-

gabenanweisungen fur zuweisungsorientierte Programme: Die Anweisung

r ? v

steht fur die pradikative Spezifikation

(r8 = 〈〉) ∨ (r8 6= 〈〉 ∧ r8 = rest(r8) ∧ v′ = first(r8))

Hier steht r8 = 〈〉 fur den Fall des leeren Eingabekanals. Falls der Eingabekanal leerist, ist der Wert der Variable im Nachfolgezustand unbestimmt. Dies wird durch dieAussage

”true“ dargestellt.

Die Anweisung

p ! v

steht fur

p′ = p8 〈v8〉Sei Q eine pradikative Spezifikation des Programms S mit Eingabekanal r und Aus-gabekanal p. Die Ruckkopplung der Ausgabe in die Eingabe laßt sich wie folgtbeschreiben. Im Programm schreiben wir dann die Anweisung:

(∗) chan r← p; S

18. Marz 2014 141


Ist Q die pradikative Spezifikation von S, so ist die pradikative Spezifikation von (*)gegeben durch:

∃ x, y : Stream α : Q[〈〉/p8, x/p′, x/r8, y/r′]

Dies charakterisiert wiederum eine Fixpunkteigenschaft durch die Gleichsetzung:

r8 = p′

Die Ruckkopplung wird wieder als Fixpunktgleichung fur den Eingabe- und Ausga-bestrom verstanden.

Beispiel 4.10: Parallele Komposition von zuweisungsorientierten Programmen

Wir betrachten folgende Anweisungen

Q1 : p ! v; r ? v

Q2 : r ? v; p ! v

S1 : chan r← p; p ! v; r ? vS2 : chan r← p; r ? v; p ! v

Q1 entspricht der pradikativen Spezifikation

p′ = p8 〈v8〉 ∧ r′ = rest(r8) ∧ v′ = first(r8)

Q2 entspricht der pradikativen Spezifikation

p′ = p8 〈first(r8)〉 ∧ (r8 = 〈〉 ∨ (r8 6= 〈〉 ∧ r′ = rest(r8) ∧ v8 = first(r8)))

(S1) ∃ x, y : x = 〈〉〈v8〉 ∧ y = rest(x) ∧ v8 = first(x)

(S2) ∃ x, y : x = 〈〉〈first(x)〉 ∧ (x = 〈〉 ∨ (x 6= 〈〉 ∧ y = rest(x) ∧ v8 = first(x)

Fur (S2) konnen wir x = y = 〈〉 wahlen, und erhalten Chaos , die Spezifikation, die

”true“ entspricht, fur S1 ist diese Wahl nicht moglich, da x = 〈〉〈v8〉 gilt. Es gilt

also fur (S1) v8 = v′. 2

Achtung: Anweisungen, die nicht terminieren, werden mit der All-Relation(”Chaos“) gleichgesetzt.

Beispiel 4.11: Erzeuger/Verbraucher mit pradikativer SpezifikationEin Erzeuger/Verbraucherprozeß kann mit asynchroner Kommunikation wie folgtbeschrieben werden. Beachte, dass es hier keine Begrenzung der Grosse des Puffersgibt. Abb. 4.23 gibt ein Datenflussdiagramm wieder.Das Programm liest sich wie folgt.

142 18. Marz 2014


Erzeuger Verbraucher

e c

ab

Abb. 4.23.: Erzeuger/Verbraucher-System als Datenflussdiagramm

chan b ← a;chan c ← e;d Erzeuger: v := product(0);

b ? s;do s then e ! v;

v := next(v);b ? s

od c‖d Verbraucher: t := true;

a ! t;do t then c ? w;

consume(t, w);a ! t

od c

Hier dient der Kanal a als Ausgabekanal des Verbrauchers und als Eingabe fur denKanal b des Erzeugers zur Synchronisation. 2

Das folgende Beispiel demonstriert die Ubersetzung eines Programms in eine pradi-kative Spezifikation.

Beispiel 4.12: Ubertragung eines Programms in eine pradikative Spezifikation

Die Anweisung

chan i← o; r ? v; o ! v ‖ i ? w; p ! w

genugt der pradikativen Spezifikation

18. Marz 2014 143


∃ x, y : Stream α :

((r = 〈〉 ∨ (r 6= 〈〉 ∧ r′ = rest(r8) ∧ v′ = first(r8) ∧ o′ = o8 〈v′〉))∧(i = 〈〉 ∨ (i 6= 〈〉 ∧ i′ = rest(i8) ∧ w′ = first(i) ∧ p′ = p8 〈w′〉)))[〈〉/o8, x/o′, x/i8, yi′]

≡∃ x, y : Stream α :

((r = 〈〉 ∨ (r 6= 〈〉 ∧ r8 = rest(r8) ∧ v′ = first(r8) ∧ x′ = 〈〉〈v′〉))∧(x = 〈〉 ∨ (x 6= 〈〉 ∧ y = rest(x) ∧ w′ = first(x) ∧ p′ = p8 〈w′〉)))≡

r = 〈〉 ∨ (r 6= 〈〉 ∧ r′ = rest(r8) ∧ v′ = first(r8) ∧ w′ = v′ ∧ p′ = p8 〈w〉)2

Achtung: Bei diesem Stil der Programmierung mit asynchroner, gepufferterKommunikation entsteht durch Parallelitat und Kommunikation kein Nichtdetermi-nismus, da die Kommunikation immer gepuffert erfolgt. Dies demonstrieren wir wiefolgt: Die Anweisung

(1) p ! v; r ? v;

ergibt

p′ = p8 〈v8〉 ∧ (r8 = 〈〉 ∨ (v′ = first(r8) ∧ r′ = rest(r8)))

Die Anweisung

(2) r ? v; p ! v

ergibt

r = 〈〉 ∨ [v′ = first(r8) ∧ r8 = rest(r8) ∧ p′ = p8 v′]

Die Kommunikation ist asynchron, gesendete Nachrichten werden gepuffert, bis derEmpfanger sie entgegennimmt. Im Fall synchroner, durch Rendezvous kommunizie-render Programme wird die Semantik deutlich komplizierter (siehe spater).

Beispiel 4.13: Addition und RuckkopplungWir betrachten eine Komponente zur paarweisen Addition der Zahlen in der Stromenauf den Kanalen x und y. Das Ergebnis enthalt der Ausgabestrom z:

ADD⇔ ∀k : Nat : 0 < k ∧ k ≤ #x8 ∧ k ≤ 1 + #y8 ⇒(z′.k = x8.k + y8.k - 1⇐ k > 1) ∧ (z′.1 = x8.1) ∧#z′ = min(#x8, 1 + #y8)

144 18. Marz 2014


wobei x.k das k-te Element im Strom bezeichnet. Die Ruckkopplung

chan y← z; ADD

fuhrt auf die pradikative Spezifikation

∃ a,b : ADD[〈〉/z8, a/z′, a/y8, b/y′]

Auffalten von ADD ergibt (die Variable b bezeichnet die verbleibende Eingabe aufdem Kanal y, die in der Formel nicht auftritt)

∃ a,b : ∀ k : Nat : k ≤ #x8 ∧ k ≤ 1 + #a⇒(z.k = x8.k + a.k - 1⇐ k > 1) ∧(z.1 = x8.1) ∧ #z = min(#x8, 1 + #a)

Demnach gilt:

z′.k =k∑

i =1

x8.i

2

Das Beispiel zeigt wie durch schematische Kombination der Spezifikationen die Spe-zifikation zusammengesetzter Systeme erzeugt werden.

4.6.2. Interaktive Systeme zuweisungsorientierter Programme

Mit den eingefuhrten Mitteln konnen wir nun die asynchronen Komponenten auchdurch Anweisungen beschreiben.

Beispiel 4.14: Hamming-Sequenz durch AnweisungenDie Hamming-Sequence haben wir im Abschnitt 4.3.1 beschrieben. In dem Beispielder Hammings Sequenz verwenden wir den Datenflussknoten (mit expliziter Copy-Funktion), der in Abb. 4.24 dargestellt ist. Das pradikative Programm zeigt diefolgende Form der Kopplung von Ausgabe- mit Eingabekanalen

zi ← z0, ai ← a0, bi ← b0, ci ← c0

Dies entspricht genau den Kanten in Abb. 4.24.Die benotigten Datenflussknoten lassen sich als zuweisungsorientierte Programme

wie folgt beschreiben.

omerge: xi ? vx; ci ? vc;do vx ≤ vc then zi ! vx; xi ? vx[] vc ≤ vx then z0 ! vc; ci ? vc od

18. Marz 2014 145


omerge

x. 1 & x

x. streammult (n,x)

cop

z0

zi

y

cxi

a

b0

bi

c

Abb. 4.24.: Datenflussknoten als Datenflussschema

copy: do true then zi ? vz; y0 ! vz; ai ! vz od

λ x.1 & x: b0 ! 1; do true then ai ? va; b0 ! va od

streammult: do true then bi ? vb; c0 ! (vb ∗ n)

Man beachte, dass die zuweisungsorientierte Beschreibung von Komponenten nureinen anderen Stil zur Programmierung des Verhaltens darstellt. 2

Die zuweisungsorientierten Programme mit Kommunikationsanweisungen lassen sichin pradikative Spezifikationen ubersetzen. Dadurch wird das Verhalten der Daten-flussknoten in Logik ausgedruckt.

4.7. Parallele Komposition von Programmen mit

gemeinsamen Variablen

Setzen wir Programme parallel zusammen, so dass sie uber gemeinsame Programm-variable kommunizieren, so mussen wir sicherstellen, dass Anweisungen, die einer-seits schreibend und andererseits lesend oder schreibend auf gemeinsame Variablen

146 18. Marz 2014

4.7. Parallele Komposition von Programmen mit gemeinsamen Variablen

zugreifen, nie gleichzeitig ausgefuhrt werden. Diese Anweisungen mussen unter ge-genseitigem Ausschluss ausgefuhrt werden. Dies heißt, dass sie in einer willkurlich(nichtdeterministisch) gewahlten Reihenfolge hintereinander ausgefuhrt werden.

Entscheidend ist bei die Granularitat der einzelnen Anweisungsfolgen, da diese be-stimmt, in welcher Weise die Anweisungen ineinander verflochten ablaufen konnen.Wir modellieren in diesem Abschnitt Anweisungen nicht mehr als Relationen zwi-schen Zustanden, sondern als Relationen zwischen Stromen von Zustanden.

4.7.1. Komposition von Aktionen auf Zustanden

Eine zustandsbasierte Komponente mit gemeinsamen Variablen modellieren wir wiefolgt. Sei Σ der Zustand, auf dem die Komponente arbeitet. Gehen wir davon aus,dass die Komponente auf gewisse Programmvariable (Attribute des Zustands) zu-greift, die auch von anderen Komponenten gelesen und/oder geschrieben werdenkonnen, so konnen wir die Wirkung (Black Box Sicht) der Komponente wir folgtcharakterisieren:

Die Komponente ist stets bereit, Zustandsubergange durchzufuhren (ist die Kom-ponente blockiert, so fuhrt sie eben einen leeren Zustandsubergang durch). Die Kom-ponente wartet, bis sie aktiviert wird. Durch einen Scheduler wird die Komponenteaktiviert. Sie fuhrt auf dem gegebenen globalen Zustand eine Reihe von Aktionendurch, die Zustandsubergange darstellen. Nach endlich vielen Schritten unterbrichtsie ihre Tatigkeit (oder wird unterbrochen). Den bis dahin erzeugten Zustand erhaltdann eine andere Komponente als Eingabe fur deren Aktivierungsphase.

Den Gesamtablauf eines Systems mit drei Komponenten konnen wir uns dann wiein Abb. 4.25 beispielhaft dargestellt vorstellen.

Wollen wir die Wirkung einer Komponente, die auf einem gemeinsamen Speicherarbeitet, unabhangig vom restlichen System darstellen, so konnen wir gemaß derbeschriebenen Idee die Wirkungsweise der Komponente wie folgt modellieren: DieKomponente erhalt in jeder Aktivierungsphase k einen Zustand σ8k und erzeugt einenZustand σ′k. Fassen wir alle Eingabezustande einer Komponente zu einem Stromzusammen und alle Ausgabezustande ebenfalls zu einem Strom, so erhalten wir zweiStrome. Die Komponente bildet einen Strom von Eingabezustanden auf einen Stromvon Ausgabezustanden ab. Wir modellieren die Wirkung einer deterministischenKomponente dementsprechend durch eine Funktion

f : Stream Σ→ Stream Σ

Die Beschreibung des Verhaltens einer Komponente durch die Angabe solch einerFunktion ist allerdings außerordentlich abstrakt und deshalb praktisch in vielenFallen nicht gut handhabbar. Fur praktische Zwecke ist es sinnvoll, eine solche Kom-ponente mit Hilfe lokaler Zustandsvariablen als Zustandsmaschine zu beschreiben.

Die syntaktische Schnittstelle einer Komponente, die auf gemeinsame Programm- syntaktischeSchnittstellevariable zugreift beschreiben wir durch die Angabe

18. Marz 2014 147


Abb. 4.25.: Aktivierungsphasen der drei Komponenten eines Systems

� der globalen (gemeinsamen) Variablen, deren Sorte und unter Umstanden, obglobale(gemeinsame)Variable

nur lesend, nur schreibend oder lesend und schreibend von der Komponenteauf die entsprechende Variable zugegriffen wird;

� der lokalen Variablen auf denen die Komponente arbeitet.lokaleVariable

Im Modell konnen wir die lokalen Variablen der Komponenten einfach als Attributedes Zustandsraums ansehen. Naturlich gilt die Regel, dass sich Werte lokaler Varia-blen einer Komponente in Zustandsubergangen anderer Komponenten nicht andern.

Beispiel 4.15: Erzeuger/Verbraucher mit Puffer der maximalen Lange nWir betrachten nun die Datenflussknoten des Erzeuger/Verbraucherproblems durchpradikative Spezifikationen.

Erzeuger:

shared buffer: var Seq Datalocal e: var Datainitial e = e0

transitions: # buffer8 < n⇒ buffer′ = buffer8 〈e〉 ∧ e′ = next(e8)# buffer = n⇒ e8 = e′ ∧ buffer8 = buffer′

148 18. Marz 2014

4.7. Parallele Komposition von Programmen mit gemeinsamen Variablen

Verbraucher:

shared buffer: var Seq Datalocal c: var Datainitial c= c0

transitions: # buffer > 0⇒ ∃ d : buffer8 = 〈d〉 buffer′ ∧ c′ = consume(c8,d)# buffer = 0⇒ c8 = c′ ∧ buffer8 = buffer′

Hierdurch werden Zustandsmaschinen beschrieben, die, wie bereits gezeigt, strom-verarbeitende Funktionen definieren. 2

Die parallele Komposition von n Komponenten, gegeben durch Verhaltensfunktionen(fur k ∈ N, 1 ≤ k ≤ n)

fk : Stream Σ→ Stream Σ

konnen wir mit Hilfe von abstrakten Schedulern definieren:

schedule : Stream[1 . . . n]× SPFn × Stream State→ Stream State

wobei SPF fur die Menge der Funktionen der Form

Stream Σ→ Stream Σ

steht. Wir spezifizieren den Scheduler durch folgende Gleichung

schedule(k & p, (f1, . . . , fn), σ & s) = σ8 & schedule(p, (f′1, . . . , f′n), s)

wobei die Funktionen f′1, . . . , f′n wie folgt definiert seien:

f′j = fj falls j 6= k

und fur alle Strome x:

fk(σ & x) = σ′ & f′k(x)

Man beachte, dass die Funktion f′k durch diese Gleichung eindeutig bestimmt ist.Fur jedes Orakel p ∈ Stream[1 . . . n] erhalten wir mit der Funktion

λ s : schedule(p, (f1, . . . , fn), s)

ein Komponentenverhalten.Ein Orakel (engl. oracle or prophecy) ist nach [BS01b] eine Komponente, die fur Orakel

(oracle)die Auswahl zwischen nichtdeterministische Alternativen benutzt wird. Wir sprechenvon einem

”Orakel“, weil dadurch die zukunftige Verhaltenweise bestimmt wird. Das

Orakel fixiert im Voraus die Wahl der Ausgaben.Ist ein Anfangszustand σ0 gegeben, so ergibt der Strom s beschrieben durch die

Gleichung

s = σ0 & schedule(p, (f1, . . . , fn), s)

den Strom der Zustande, den wir erhalten indem wir die n Komponenten, derenSchnittstellenverhalten durch die Funktionen f1, . . . , fn beschrieben ist, parallel ab-laufen lassen, ohne dass weitere Komponenten einwirken.

18. Marz 2014 149


4.8. Historische Bemerkungen zur Struktur- und

Verteilungssicht

Die Struktur- oder auch Verteilungssicht wurde fruh in der Informatik als ein wesent-liches Mittel zur Verstandnis eines Systems erkannt. Die Struktur wird dabei haufigdurch das Stichwort Architektur bezeichnet. In vielen pragmatischen Ansatzen desSoftware Engineerings finden sich Vorschlage, fruhzeitig bei einer Systementwick-lung, insbesondere im Design, die Struktur- oder Verteilungssicht, die Software-oder Systemarchitektur, klar zu dokumentieren.

Ein fruhes Beispiel ist der Ansatz von Douglas Ross unter dem Stichwort SADT(Structure Analysis and Design Technique, vgl. [Ros77] und [Ros90]) und Ansatzevon Michael Jackson unter dem Stichwort

”Jackson Systems Development – JSD“

(vgl. [Jac83]).

Unter dem Stichwort”Structured Analysis“ finden sich eine Vielzahl von Vor-

schlagen, in denen jeweils Datenflusssichten fur Systeme angegeben werden, die diekonzeptuelle Verteilung und strukturelle Aufteilung eines Systems darstellen unddie Informationsflusse zwischen den Systemteilen (vgl. z.B. [DeM79]).

Spater wurden diese Arbeiten unter dem Stichwort der Softwarearchitektur weiter-gefuhrt und vertieft. Umfangreiche Architekturbeschreibungssprachen wurden ent-wickelt, wie beispielswese Wright (vgl. [GAO95]) und Rapide (vgl. [LKA+95]). Dabeimuss man sich klar vor Augen fuhren, dass es sich bei Architekturbeschreibungsspra-chen grundsatzlich um Beschreibungssprachen fur verteilte, interagierende Systemehandelt. Wichtig ist dabei, dass nicht nur die grafische Darstellung der einzelnenKomponenten und ihrer Kommunikationsverbindungen in einer Architekturbeschrei-bung dokumentiert werden, sondern vielmehr auch das Verhalten der Komponentenund das Zusammenwirken der Komponenten zur Generierung des gewunschten Sys-temgesamtverhaltens.

Eine Reihe fruher Ansatze zielt auch darauf, die Struktur der Systeme darzustel-len. Auch in Petrinetzen und den daraus hervorgegangenen Datenflussdiagrammenist dies der Fall.

Haufig finden sich in praktischeren Arbeiten zum Thema der Architektur vonBetriebssystemen, zu Softwarearchitekturen oder Design Patterns (vgl. [GHJV95])informelle Systemstrukturdiagramme, die die Verteilungsarchitektur von Systemenillustrieren. Meist handelt es sich hierbei um Architekturskizzen, die die Strukturverteilter Systeme veranschaulichen sollen. Im verangangenen Text haben wir ver-sucht zu zeigen, wie die Struktur verteilter Systeme, also auch die Architektur vonSystemen direkt durch die formalen Modellierungstechniken, die wir entwickelt ha-ben, dargestellt werden konnen.

Wichtig ist dabei darauf hinzuweisen, dass eine modulare hierarchische Struktu-rierung von Systemen wichtige Ingenieurprinzipien ermoglicht. Legt man die Ar-chitektur fest und die Schnittstellen der beteiligten Komponenten, so konnen dieKomponenten voneinander unabhangig entwickelt und verifiziert werden, zudem ist

150 18. Marz 2014

4.8. Historische Bemerkungen zur Struktur- und Verteilungssicht

es moglich, eine stufenweise Integration vorzunehmen und auch in der Integrationder Architektur- und der Qualitatssicherung der Architektur und der Verifikationihre Korrektheit in Hinblick auf das Gesamtsystemverhalten, unabhangig von denKomponentenimplementierungen zu argumentieren.

18. Marz 2014 151


152 18. Marz 2014

5. Ablaufsicht: Prozesse als Ablaufeverteilter Systeme

In diesem Kapitel behandeln wir die Ablauf- oder Prozesssicht auf Systeme. DasVerhalten von Systemen wird dabei durch Mengen von Ablaufen (engl.

”Traces“)

oder Prozessen beschrieben. Ein Ablauf besteht aus einer Menge diskreter Ereig-nisse, die Instanzen von Aktionen darstellen und in einer zeitlichen oder kausalerBeziehung zueinander stehen. Wir formalisieren im folgenden Kapitel den BegriffAblauf beziehungsweise Prozess.

Ein verteiltes System besteht – wie im vorangegangenen Kapitel erlautert – auseiner Familie von Komponenten (auch Akteure oder Agenten genannt), die in ei-ner zeitlichen und raumlichen Verteilung Aktionen ausfuhren. Jede dieser Aktionenkann Teile des Zustands eines Systems andern (entspricht also der Ausfuhrung einerAnweisung) sowie den Empfang oder das Senden von Nachrichten einschließen. Ak- Nebenlaufig-

keittionen konnen (wie Anweisungen in einem Programm) mehrfach ausgefuhrt werden.Gewisse Aktionen stehen in einer kausalen Beziehung (einer Ursache/Wirkungsbe-ziehung), die erzwingt, dass die Aktionen hintereinander ausgefuhrt werden. Es ent-stehen nichtsequentielle,

”parallele“ Ablaufe. Wir sprechen auch von Nebenlaufigkeit.

Sequentielle Systeme haben sequentielle Ablaufe, parallele Systeme haben parallele,nebenlaufige Ablaufe, bei denen nur gewisse Aktionen sequentiell zueinander ablau-fen.

Die Komponenten eines Systems sind entweder durch Kanale zum Austausch vonNachrichten verbunden oder koordinieren sich uber gemeinsamen Speicher. Umfangund Anzahl der Komponenten konnen sich dynamisch, das heißt wahrend des Ab-laufs des Systems, andern. Dann ist es oft schwierig, das dynamische Verhalten einesverteilten Systems allein durch die Menge seiner Komponenten zu beschreiben. Einesehr allgemeine, vom Begriff der Komponente unabhangige Beschreibung des dyna-mischen Verhaltens verteilter Systeme erhalten wir durch die Charakterisierung derMenge der Ablaufe eines Systems.

5.1. Nebenlaufige Prozesse

Die Ablaufe eines Systems bilden wir uber der Menge der Aktionen und mit Hilfe Aktionen

der Kausalitatsbeziehungen zwischen den Ereignissen, die Instanzen der Aktionen Kausalitats-beziehungdarstellen. Die Ausfuhrung einer Aktion nennen wir ein Ereignis. Ein Ereignis istEreignisdie Instanz einer Aktion. Das Verhalten eines Systems ist dann durch die Menge

18. Marz 2014 153

Kapitel 5. Ablaufsicht: Prozesse als Ablaufe verteilter Systeme

seiner ausgefuhrten Aktionen, die Ereignisse, und seinen Ablaufe beschrieben.Typischerweise gibt es fur Systeme eine große Menge unterschiedlicher Ablaufe,

die jeder fur sich recht umfangreich, oft unendlich sind. Sie erhalten eine große Zahlvon Ereignissen und Aktionen. In vielen Fallen ist auch die Menge der Aktionen un-endlich. Deshalb ist es in aller Regel schwierig, die Menge der Ablaufe eines Systemsgenau zu beschreiben. In der Praxis werden deshalb oft vereinfachte Beispielablaufe(Szenarien, dargestellt etwa durch Interaktionsdiagramme als Instanzen von

”Use

cases“ in der Objektorientierung) durch so genannte”Message-Sequence-Charts“

beschrieben. Formal beschreiben wir die Ablaufe eines Systems durch die Beschrei-bung der Menge der Aktionen, sowie die Menge der Ereignisse und ihre Anordnung(kausale Abhangigkeit) in Prozessen.

5.1.1. Aktionsstrukturen

Die Menge der Aktionen eines Systems bezeichnen wir mit

Action

Die Menge der Aktionen kann beispielsweise mit den Mitteln der Datenmodellierung,etwa in Form algebraischer Spezifikation durch die Angabe einer Sorte beschriebenwerden. Da in einem Ablauf eines Systems gewisse Aktionen mehrfach auftretenkonnen, verwenden wir zur Kennzeichnung der einzelnen Instanzen der gleichenAktion innerhalb eines Ablaufs eine Menge von Ereignissen. Diese Menge bezeichnenEreignis

wir mit

Event

Wieder konnen wir die Menge der Ereignisse in axiomatischen Spezifikationen durcheine Sorte beschreiben.

Ein Ablauf eines Systems besteht aus einer partiell (kausal) geordneten Menge vonEreignissen; jedem Ereignis ist eine Aktion zugeordnet. Mathematisch ausgedruckt:Ein Ablauf ist gegeben durch eine partielle Ordnung

≤: Event, Event→ Bool Kausalordnung

auf einer Menge Event von Ereignissen und eine Abbildung

act : Event→ Action Ereignismarkierung

die jedem Ereignis eine Aktion zuordnet.

Definition: ProzessWir nennen das Paar (≤,act) eine Aktionsstruktur oder einen Prozess uber derAktions-

strukturProzess

Sorte Event und bezeichnen mit dom(act) seine Ereignismenge und mit rng(act) sei-ne Aktionsmenge. 2

154 18. Marz 2014


Man beachte: Die Kausalitatsbeziehung

e1 ≤ e2

zwischen zwei Ereignissen in einem Prozess p bedeutet, dass das Ereignis e2 zwin-gend das Ereignis e1 voraussetzt. Dies impliziert auch eine zeitliche Beziehung zwi-schen den Ereignissen e1 und e2. Das Ereignis e1 findet vor dem Ereignis e2 statt.Die Umkehrung gilt nicht. Aus der Tatsache, dass ein Ereignis e zeitlich vor einemEreignis e′ stattfindet, kann naturlich auf keinen kausalen Zusammenhang geschlos-sen werden.

Aus nahe liegenden Grunden betrachten wir nur Aktionsstrukturen (≤, act), furdie gilt, dass fur jedes Ereignis e die Menge der Ereignisse, die fur e kausal sind,endlich ist. Mathematisch ausgedruckt, betrachten wir nur partielle Ordnungen alsKausalitatsordnungen fur Aktionsstrukturen, fur die folgende Aussage gilt:

∀ e ∈ dom(act) : |{c ∈ dom(act) : c ≤ e}| <∞

Die Menge der Aktionsstrukturen uber der Aktionenmenge Action bezeichnen wirmit

sort ActStruct Action

Diese Menge der Aktionsstrukturen konnen wir wieder mit axiomatischen Technikendurch eine Sorte spezifizieren.

Wir studieren im folgenden eine Reihe charakteristischer Eigenschaften von Akti-onsstrukturen, wie sie typischerweise fur Systemablaufe vorausgesetzt werden konnen.

Eine Aktionsstruktur (≤, act) heißt endlich fundiert, wenn fur jedes Ereignis e dieMenge der Ereignisse, die fur e kausal sind, endlich ist. Mathematisch ausgedruckt,gilt:

∀ e ∈ dom(Action) : |{e′ ∈ dom(Action) : e′ ≤ e}| <∞

Endliche Fundierung entspricht der Eigenschaft realer Systeme, dass nur Ereignissestattfinden konnen, die nur endlich viele Ereignisse kausal benotigen. Mit

ActStruct Action

bezeichnen wir im Weiteren die Menge aller endlich fundierten Aktionsstrukturenuber einer gegebenen Aktionenmenge Action, mit

ActStructfin Action

die Menge aller endlichen Aktionsstrukturen, das heißt, die Menge aller Aktionss-trukturen (≤, act) mit endlichen Ereignismengen. Fur endliche Aktionsstrukturegilt:

|dom(act)| <∞

18. Marz 2014 155


Aktionsstrukturen ergeben ein Modell fur das Verhalten verteilter Systeme, in demNebenlaufigkeit (zeitliches Nebeneinander) explizit ausdruckbar ist.

Wir unterscheiden zwischen vollstandigen und unvollstandigen Ablaufen eines Sys-tems. Ein unvollstandiger Ablauf enthalt – anschaulich gesprochen – alle Ereignis- unvollstandi-

ger Ablaufse eines Systemablaufs bis zu einem bestimmten, willkurlich gewahlten Zeitpunkt.Ein unvollstandiger endlicher Ablauf entspricht also einer unvollstandigen (zu ei-nem bestimmten Zeitpunkt abgebrochenen) Beobachtung eines Systemablaufs. Einvollstandiger Ablauf enthalt alle Ereignisse und Aktionen vom Start eines Systemsvollstandiger

Ablauf ohne zeitliche Beschrankung.Um die Struktur von Prozessen genauer analysieren zu konnen, definieren wir eine

partielle Ordnung v, genannt Prafixordnung, auf der Menge der Ablaufe wie folgt:Prafix-ordnung

(≤,act) v (≤′,act′) ≡dom(act) ⊆ dom(act′) ∧(≤′,act′)|dom(act) = (≤,act) ∧∀e, e′ ∈ dom(act′) : e ≤ e′ ∧ e′ ∈ dom(act)⇒ e ∈ dom(act)

Ein Prozess ist Prafix eines Prozesses, wenn er aus diesem durch Weglassen gewisserEreignisse, entsteht, wobei ein Ereignis e weggelassen werden muss, wenn ein anderesEreignis weggelassen wird, das fur e als kausal benotigt wird. Durch diese Ordnungist die Menge der Aktionsstrukturen uber einer Ereignismenge vollstandig partiellgeordnet. Gilt p v p′ und p 6= p′, dann ist p unvollstandiger Ablauf. Durch dieForderung nach endlicher Fundierung wird sichergestellt, dass jeder Prozess in derPrafixordnung eine kleinste obere Schranke hat.

Das Verhalten eines Systems ist durch die Menge seiner Aktionen und die MengeT seiner (vollstandigen) Ablaufe beschrieben.

5.1.2. Eigenschaften von Prozessen

Jede Aktionsstruktur modelliert einen Ablauf eines Systems und damit ein moglichesSystemverhalten uber ein bestimmtes endliches oder auch unendliches Zeitintervall(mit gleichem Anfangspunkt). Ein Prafix eines Ablaufs reprasentiert einen Ablaufuber ein kurzeres Zeitintervall.

Fur die Menge der Aktionsstrukturen gelten folgende Aussagen:

� Jeder unvollstandige Ablauf ist Prafix eines vollstandigen Ablaufs.

� Jeder (vollstandige) Ablauf ist durch die Menge seiner endlichen Prafixe (un-vollstandigen Ablaufe) eindeutig charakterisiert.

Einem parallelen Programm konnen wir fur einen gegebenen Anfangszustand eineMenge von Ablaufen zuordnen, wobei die Aktionen die Einzelanweisungen (Zuwei-sungen) sind.

156 18. Marz 2014


Beispiel 5.1: Programmablauf mit SemaphorenDas Programm

semaphor s := 1;

d do true then a; P(s); b; V(s) od ‖ do true then c; P(s); d; V(s) od c

besitzt beispielsweise den in Abb. 5.1 angegebenen Ablauf. Die SemaphoraktionenP(s) und V(s) arbeiten auf der gemeinsamen Variablen s, dem Semaphor, und stehendeshalb in kausaler Beziehung. 2

a

b

a

b

P(s)

V(s)

c

d

c

P(s)

P(s)

V(s)

V(s)

Abb. 5.1.: Beispiel fur Ablauf

Die Menge der Ablaufe eines Systems lassen sich durch Pradikate

P : ActStruct α→ B

festlegen. Die Pradikate beschreiben jeweils eine Menge von Prozessen durch Eigen-schaften. Die Menge der Ablaufe eines Systems lassen sich also durch die Menge derEigenschaften seiner Ablaufe beschreiben.

Wir unterscheiden zwei Klassen von Eigenschaften bei diesen Pradikaten uberProzessen:

1. Sicherheitsbedingungen schließen bestimmte unerwunschte, bereits an endli- Sicherheitsbedingungen

chen Teilprozessen beobachtbare Verhaltensmuster aus (vgl. partielle Korrekt-heit).

2. Lebendigkeitsbedingungen stellen sicher, dass bestimmte Aktionen schließlich Lebendigkeits-bedingungenauftreten (vgl. robuste Korrektheit, Terminierung).

18. Marz 2014 157


Wir geben spater eine formale Definition fur diese Klasse von Pradikaten. Systemei-genschaften sind meist Mischungen aus Sicherheits- und Lebendigkeitseigenschaften.Jede Systemeigenschaft lasst sich in eine reine Sicherheits- und eine reine Lebendig-keitseigenschaft aufspalten.

Beispiel 5.2: Sicherheits- und LebendigkeitsbedingungenWir betrachten ein System mit der Menge {a,b, c,d} von Aktionen.(1) Sicherheitsbedingungen sind beispielsweise:

� die Aktionen b und d sind gegenseitig ausgeschlossen (finden nur hintereinan-der und nie nebeneinander statt),

� die Aktionen a und b finden (wenn uberhaupt) sequentiell abwechselnd statt,

� die Aktionen c und d finden (wenn uberhaupt) sequentiell abwechselnd statt,

� in jedem Prafix ist die Anzahl der P(s) Aktionen hochstens um 1 großer als dieAnzahl der V(s)-Aktionen.

(2) Lebendigkeitsbedingungen sind beispielsweise:

� nach jeder Aktion b findet schließlich eine Aktion a statt,

� nach jeder Aktion d findet schließlich eine Aktion c statt,

� nach jeder Aktion a (oder c) findet schließlich eine Aktion b oder eine Aktiond statt.

Der pathologische Ablauf aus Abb. 5.2 ist durch diese Bedingungen allerdings nichtausgeschlossen. Dieser Ablauf wird durch die Hinzunahme der folgenden Lebendig-keitsbedingungen (auch Fairnessannahmen genannt) ausgeschlossen:

� nach der Aktion a findet stets schließlich auch eine Aktion b statt, nach c stetsschließlich d,

� nach der Aktion b findet stets schließlich auch eine Aktion a statt, nach d stetsschließlich c.

Wir konnen Systemeigenschaften immer in Lebendigkeits- und Sicherheitseigen-schaften aufspalten. 2

Typischerweise formulieren wir Sicherheitsbedingungen durch Pradikate auf der Men-ge der Ablaufe, die fur alle endlichen (unvollstandigen) Teilablaufe eines Systemsgelten (auch zur permanente

”Invariante“ verwandt). LebendigkeitsbedingungenInvariante

formulieren wir hingegen durch Pradikate, die fur die vollstandigen Ablaufe geltenmussen.

158 18. Marz 2014


Gilt ein Pradikat fur alle endlichen (Prafix-)Ablaufe eines Systems, so sprechenwir, wie bei Zustanden, von einer (permanenten) Invariante. Sicherheitsbedingungenlassen sich stets als permanente Invariante deuten und auch so beschreiben.

Fur unser Beispiel ist eine permanente Invariante, dass die Differenzen der jewei-ligen Anzahl der

� mit a mit den mit b markierten Ereignissen,

� mit c markierte Ereignisse mit den mit d markierten Ereignisse,

� mit P(s) mit den mit V(s) markierten Ereignisse,

stets genau durch 1 beschrankt ist.

a

b

a

P(s)

V(s)

c

P(s)

P(s)

V(s)

V(s)

b

b

a

a

Abb. 5.2.: Unfairer Ablauf

Wir geben nun formale Definition der Begriffe Sicherheits- und Lebendigkeitseigen-schaft. Ein Pradikat

P : ActStruct Action→ B

heißt (reine) Sicherheitseigenschaft, wenn die folgende Formel gilt:

P(t) ≡ (∀ s ∈ ActStructfin Action : ∃ t ∈ ActStruct Action : s v t⇒ P(s))

Ein Pradikat P heißt (reine) Lebendigkeitseigenschaft, wenn gilt:

∀ s ∈ ActStructfin Action : ∃ t ∈ ActStruct Action : s v t ∧ P(t)

18. Marz 2014 159


Ein Pradikat ist also eine reine Sicherheitseigenschaft, wenn es fur einen Prozess ge-nau dann gilt, wenn es fur alle seine endlichen Teilprozesse gilt. Ein Pradikat ist einereine Lebendigkeitseigenschaft, wenn jeder endliche Prozess zu einem unendlichenProzess fortgesetzt werden kann, der das Pradikat erfullt. Demnach kann durch dieBetrachtung der Menge der endlichen Teilprozesse eines Prozesses nichts uber dieErfullung einer Lebendigkeitseigenschaft ausgesagt werden.

Jedes Pradikat lasst sich in eine reine Sicherheitseigenschaft und eine Lebendig-keitseigenschaft zerlegen (vgl. [GS93]). Dies gibt einen Ansatz fur die Strukturierungvon Systembeschreibungen.

Damit konnen wir wesentliche Charakteristika von Prozessen als Modelle verteilterSysteme kurz zusammenfassen:

� Prozesse konnen unendlich sein,

� Prozesse konnen sequentiell sein; dann sind alle Ereignisse in einer linearenOrdnung.

� Ein Systemverhalten entspricht einer Menge von Prozessen.

� Das Verhalten von Systemen konnen wir beschreiben, in dem wir die Mengeder Prozesse angeben, die Systemablaufe entsprechen.

Wichtige Klassen von Eigenschaften der Prozesse sind wie bereits formal beschrie-ben:

� Sicherheitseigenschaften (engl.”Safety Properties“)

� Lebendigkeitseigenschaften (engl.”Liveness Properties“)

Oft ist es fur die Beschreibung und die Analyse von Prozessen nutzlich, die Eigen-schaften in Sicherheits- und Lebendigkeitseigenschaften zu unterteilen. Auch bei derVerifikation der Eigenschaften ist diese Unterteilung hilfreich.

5.1.3. Sequentielle Prozesse als Strome von Aktionen

Ein sequentieller Prozess besteht aus einer linear geordneten Menge von Ereignissen.Jeder sequentielle Prozess kann als Strom von Aktionen dargestellt werden.

Ist fur eine endlich fundierte Aktionsstruktur (≤, act) die Kausalitatsordnung ≤lineare Ordnung, so lasst sich die Aktionsstruktur (≤, act) auch durch einen Stromvon Aktionen trace(≤,act) ∈ Stream Action darstellen:

dom(act) = ∅⇒ trace(≤,act) = 〈〉,e ∈ dom(act) ∧ (∀ e′ ∈ dom(act) : e ≤ e′)⇒

trace(≤,act) = act(e) & trace(≤,act)|dom(act)\{e})

160 18. Marz 2014

5.2. Ablaufe als Zustandsfolgen und temporale Logik

Ein Strom von Aktionen, also eine endliche oder unendliche Sequenz von Aktionen,kann somit als Spezialfall einer Aktionsstruktur aufgefasst werden. Wir verwendenals

”kanonische“ Ereignismengen die Intervalle [1 . . . n] naturlicher Zahlen mit n ∈

N∪{∞} und der klassischen Ordnung ≤. Werden allgemein Ablaufe durch die Mengeihrer Sequentialisierungen dargestellt, spricht man von Interleaving.


Strome von Zustanden und/oder Aktionen entsprechen sequentiellen Ablaufen. Ei-genschaften von Stromen lassen sich durch Pradikate

P : Stream α→ B

beschreiben. Ein einfaches Beispiel ist ein Pradikat, das das erste und zweite Elementin einem Strom vergleicht:

P(s) = (first(s) = first(rest(s)))

Eine besondere Technik zur Formulierung von Pradikaten uber unendlichen Zustands-oder Aktionsstromen erlaubt die temporale Logik. Wir betrachten im folgenden die temporale

Logikso genannte”Linear Time Temporal Logic“ (kurz LTL), die uber Sequenzen von

Systemzustanden spricht.Sei α eine Sorte und sei Q ein Pradikat uber der Menge Stream α, d.h.

Q : Stream α→ B

dann erhalten wir neue Pradikate uber der Menge Stream α durch die folgendenFestlegungen (wobei rest(σ&s) = s und rest0(s) = s und resti+1(s) = rest(rest(s)) gelte)

(◦ Q)(s) ≡ Q(rest(s)) Nexttime(♦ Q)(s) ≡ ∃ i ∈ N : Q(resti(s)) Sometimes(2 Q)(s) ≡ ∀ i ∈ N : Q(resti(s)) Always(Q until Q′)(s) ≡ ∃ i ∈ N : ∀ j ∈ N : (j < i⇒ Q(restj(s))) ∧ Q′(resti(s))

Fur jedes Pradikat Q auf Stromen ist ◦ Q, ♦ Q und 2 Q wieder ein Pradikat aufStromen. Sind Q und Q′ Pradikate auf Stromen, so ist auch Q until Q′ ein Pradikat aufStromen. Die Symbole ◦, ♦, 2 und until konnen wir als Pradikatentransformatorenauf Pradikaten fur Strome auffassen.

Wir erweitern Pradikate R uber der Sorte α

R : α→ B

zu Pradikaten uber der Sorte Stream α durch folgende Festlegung

R(s) = R(first(s))

18. Marz 2014 161


Somit erhalten wir fur gegebene Pradikate auf der Menge α Pradikate und tem-porallogische Ausdrucke fur Strome.

Meist werden in der temporalen Logik allerdings nicht Strome von Aktionen son-dern Strome von Zustanden betrachtet. Zustande sind dabei Abbildungen (

”Bele-

gungen“) von Variablen (Attributen) auf Werte. Pradikate auf Zustanden lassen sichdurch pradikatenlogische Ausdrucke angeben, in denen die Attribute der Zustandeals Variablen frei vorkommen. Wir sprechen von Zusicherungen.

Betrachten wir eine Menge Σ von Zustanden, die durch Belegungen von Variablengegeben sind, so konnen Pradikate

Q : Σ→ B

als”Zusicherungen“ durch pradikatenlogische Ausdrucke geschrieben werden. Sind

x und y Variablen der Sorte Nat (also Attribute des Zustands Σ) so ist

x ≥ y

solch eine Zusicherung.Temporallogische Formeln erlauben es uns, Aussagen uber Strome von Zustanden

zu machen. So schreiben wir etwa mit der Zusicherung x ≥ y temporallogische For-meln mit der jeweilig angegebenen Bedeutung

x ≥ y Aussage x ≥ y gilt fur ersten Zustand im Strom◦ x ≥ y Aussage x ≥ y gilt fur zweiten Zustand im Strom2 x ≥ y Aussage x ≥ y gilt fur alle Zustande im Strom♦ x ≥ y Aussage x ≥ y gilt irgendwann im Stromx ≥ y until x = 0 Irgendwann gilt x = 0 und davor gilt bis dahin x ≥ y

Temporale Operatoren konnen auch geschachtelt angewandt werden. Die temporal-logische Formel

◦ 2 x ≥ y

besagt, dass fur alle Zustande außer fur den ersten Zustand x ≥ y gilt.Eine wichtige Eigenschaft von Systemen in Bezug auf die gegebenen Pradikaten

Q und P auf Stromen ist die so genannte leads-to-Eigenschaft

Q leads to P

Diese Aussage steht fur die temporallogische Formel

2 (Q⇒ ♦ P)

Diese Aussage druckt aus, dass falls irgendwann im Strom das Pradikat Q gilt,irgendwann danach P gilt.

162 18. Marz 2014


Temporallogisch wird Stabilitat eines Pradikats durch die folgende Aussage aus-gedruckt:

2 (P⇒ 2 P)

Dies besagt, dass falls P fur einen Zustand im Strom gilt, von da an P stets gilt.

Wir haben temporallogische Ausdrucke als spezielle Notation eingefuhrt, die sichauf eine rein pradikatenlogische Schreibweise syntaktisch zuruckfuhren lasst. Es las-sen sich aber auch spezielle Umformungsregeln (

”Inferenzregeln“) fur temporale For-

meln angeben (siehe [vB91]). Es entsteht eine im eigentlichen Sinn temporale Logik.

Neben den temporalen Formeln uber Stromen (unendlichen Sequenzen) existie-ren auch Konzepte von temporalen Formeln uber Mengen von Ablaufen, die inBaumstrukturen angeordnet sind (

”branching time temporal logic“, siehe [BG93]

und [BVW94]). Solche Strukturen erhalten wir, falls wir die Verzweigungen vonSystemen in unterschiedliche Ablaufe wiederspiegeln wollen. Im ersten Fall spre-chen wir von

”Linear Time Temporal Logic“, im zweiten Fall von

”Branching Time

Temporal Logic“.

Haufig wollen wir durch Spezifikationen einen Strom nicht eindeutig charakteri-sieren, sondern nur gewisse Eigenschaften formulieren. Beispiele fur solche Eigen-schaften sind durch folgende temporallogische Formeln gegeben:

(1) Pradikat Q fuhrt auf R (Lebendigkeitsbedingung)2 (Q⇒ ♦ R)

(2) Pradikat R erfordert Q (Sicherheitsbedingung)entspricht folgender Aussage uber den Strom s:∀ s′,a : |s′| <∞ ∧ s′ 〈a〉 v s ∧ R(a) ⇒ ∃ s′′,b : s′′ 〈b〉 v s′ ∧ Q(b)

Beispiele fur solche Bedingungen bei der Spezifikation von mechanischen Systemensind vielfaltig.

Beispiel 5.3: LiftDie Bewegungen eines Lifts konnen durch eine Reihe von Regeln beschrieben werden,die Sicherheits- und Lebendingkeitsbedingungen umfassen. Zwei einfache Beispielewerden im folgenden betrachtet:

� Wird der Lift angefordert, so halt er auch irgendwann im entsprechendenStockwerk.

� Fahrt der Lift bis ins oberste Stockwerk, so wurde er dafur angefordert.

Im ersten Fall handelt es sich um eine Lebendigkeitsbedingung, im zweiten Fall umeine Sicherheitseigenschaft. 2

18. Marz 2014 163


In Ablaufsicht modellieren wir Systeme durch Angabe der Strome von Aktionen, diein einem System auftreten konnen (vgl. Ablaufsicht).

Auch stromverarbeitende Funktionen konnen wir durch Aufspaltung ihrer Eigen-schaften in Lebendigkeits- und Sicherheitsbedingungen mit Hilfe von linearer tem-poraler Logik beschreiben. Ferner konnen wir bestimmte Schemata zur Spezifikationverwenden. Wir betrachten einen einfachen Fall der Spezifikation der Funktion

f : Stream α→ Stream β

Hierbei schreiben wir ♦ x : Q um auszudrucken, dass fur den Strom x die Formel Qfur einen Reststrom gilt; formal ∃ i ∈ N : Q[(resti(x) / x].

Wir erhalten einfache Spezifikationen durch:

(1) Q in der Eingabe fuhrt auf R in der Ausgabe∀ x, y : y = f(x)⇒ (♦ x : Q(first(x)))⇒ (♦ y : R(first(y)))

(2) R in der Ausgabe erfordert Q in der Eingabe:∀ x, y : y = f(x)⇒ (♦ y : R(first(y)))⇒ (♦ x : Q(first(x)))

Lineare temporale Logik stellt logische Ausdrucksformen zur Verfugung, die gezieltauf lineare Ablaufe in der Form von Zustandsfolgen ausgerichtet ist.

5.3. Koordination, gegenseitiger Ausschluss

Gewisse Aktionen verteilter Systemen konnen kausal vollig unabhangig von einanderund auch nebeneinander ausgefuhrt werden. Dies wird dadurch modelliert, dass inallen Ablaufen bestimmte Ereignisse, die mit entsprechenden Aktionen markiertsind, ohne kausale Abhangigkeit sind.

Bei nicht unabhangigen Aktionen in Ablaufen eines Systems unterscheiden wirfolgende zwei Falle:

(1) Gegenseitiger Ausschluss : Es durfen gewisse Aktionen a, b in einem Ablaufnicht nebeneinander auftreten, das heißt, gilt fur Ereignisse e, e′ stets

act(e) = a ∧ act(e′) = b⇒ (e ≤ e′ ∨ e′ ≤ e)

(2) Echte Kausalitat auf Aktionen: Eine Aktion a heißt eins-zu-eins kausal fureine Aktion b, wenn fur alle Prafixe q = (≤,act) unvollstandiger Ablaufeeines Systems die folgende Aussage gilt:

#(q,a) ≥ #(q,b).

Hier bezeichnet #(q,a) die Anzahl der Ereignisse in q, die mit der Aktion amarkiert sind. Ausfuhrlich formuliert erhalten wir

|{e ∈ dom(act) : act(e) = a}| ≥ |{e ∈ dom(act) : act(e) = b}| Sicherheit

164 18. Marz 2014


und fur alle vollstandigen Ablaufe

|{e ∈ dom(act) : act(e) = a}| = |{e ∈ dom(act) : act(e) = b}| Lebendigkeit

gilt. Kurzer ausgedruckt gilt #(q,a) = #(q,b). Mit anderen Worten heißtdas, dass jede Aktion a jeweils eine Aktion b nach sich zieht, und jedes b nurstattfinden kann, wenn davor ein a stattgefunden hat.

Betrachten wir Zustandsfolgen mit Zustanden, in denen wir Zahler #a,#b fur dieZahl der Aktionen a und b haben, so schreiben wir (fur alle k ∈ N):1

2 (#a > k ⇒ ♦ #b > k) Lebendigkeit

2 #a ≥ #b Sicherheit

Daneben existiert eine Fulle von moglichen anderen Beziehungsarten zwischen denAktionen in den Ablaufen von Systemen. Gewisse Beschreibungsmittel sind beson-ders darauf ausgerichtet, diese Formen der echt kausalen Beziehungen zwischen Ak-tionen in Ablaufen zu beschreiben.

Beispiel 5.4: Petri-Netze als Pradikate uber Ablaufen Petri-Netz

Petri-Netze (genauer Stellen-/Transitionsnetze, vgl. [Rei90]) konnen als Beschrei-bung von Mengen von Ablaufen und somit als Pradikate uber Ablaufen aufgefasstwerden. Die Aktionen entsprechen in Petri-Netzen den Knoten, die Transitionengenannt werden. Ein einzelner Schaltvorgang entspricht einem Ereignis.

Jede Stelle (vgl. Abb. 5.3) in einem Petri-Netz entspricht der folgenden Aussageuber die Ablaufe des beschriebenen Systems:

Fur alle endlichen Prafixe act von Ablaufen des durch das Netz beschriebenenSystems gilt die folgende Sicherheitsbedingung:

|{e ∈ dom(act) : act(e) ∈ {a1, . . . ,an}}|+ k≥ |{edom(act) : act(e) ∈ {b1, . . . ,bm}}|

Ein Petri-Netz entspricht in dieser Auffassung der Angabe dieser Sicherheitsbedin-gung fur jede Stelle im Netz.

Wir konnen die Formel auch anders schreiben, wenn wir die folgende Notationeinfuhren. Sei q Aktionsstruktur und a eine Aktion. Mit a # q bezeichnen wir dieAnzahl der Ereignisse in q, die der Aktion a zuordnet sind:

a # q = {e ∈ dom(q) : act(e) = a}

Die Schreibweise lasst sich auf Mengen A von Aktionen erweitern:

A # q = {e ∈ dom(q) : act(e) ∈ A}1Man beachte, dass wir in der temporalen Logik die Lebendigkeit anders ausdrucken mussen.

18. Marz 2014 165


k

...

...

a1

bmb1

an

Abb. 5.3.: Stelle in einem Petri-Netz

Damit schreibt sich die obige Forderung an die endlichen Prafixe q von Ablaufen inPetri-Netzen wie folgt:

{a1, . . . ,an} # q + k ≥ {b1, . . . ,bm} # q

Uber die Anzahl der Aktionen in Prozessen oder endlichen Prafixen konnen wir mitHilfe dieser Notation eine ganze Reihe von Eigenschaften geschickt formulieren.

Beispiel 5.5: Ablaufe in Petri-Netzen(1) Betrachten wir den folgenden Ausschnitt eines Petri-Netzes (vgl. Abb. 5.4) soerhalten wir fur Ablaufe p stets: Fur alle q v p gilt:

a#q ≥ b#q

(2) Wir betrachten das Petri-Netz in Abb. 5.5. Fur die Prafixe der Ablaufe diesesNetzes ergeben sich aus dem Netz folgende Aussagen:

a#q ≥ b#q

b#q + 1 ≥ c#q

v#q ≥ b#q + d#q

b#q + d#q + 1 ≥ v#q

c#q ≥ d#q

1 + d#q ≥ c#q2

166 18. Marz 2014


a

b

Abb. 5.4.: Einfaches Petri-Netz

•

a b cdv

••

Abb. 5.5.: Einfaches Petri-Netz

Mit dieser Technik der Ubersetzung erfassen wir nur Sicherheitseigenschaften. Da-neben existieren gewisse Lebendigkeitseigenschaften fur Petri-Netze, die im wesent-lichen in der Aussage bestehen, dass solange eine Transition schaltbereit ist, im-mer auch eine Transition schaltet. Bezogen auf Ablaufe heißt das, dass endlichevollstandige Ablaufe maximal bzgl. der Prafix-Ordnung sind.

Neben temporaler Logik und Petri-Netzen existiert eine Vielzahl weiterer Be-schreibungstechniken fur die Wiedergabe von Ablaufen verteilter Systeme. Beispielesind

� UML (Unified Modeling Language) mit seinen Aktions- und Interaktionsdia-grammen: vgl. [Bur97], [FT01] und [GB99];

� SDL (Specification and Description Language) mit seinen Sequenzdiagram-men (engl. Message Sequence Charts): vgl. [Bro91], Web Forum Tutorial -http://eig.unige.ch/lii/Fichiers Distr/SYR/Telelogic.pdf;

� ARIS mit seinen Prozessdiagrammen: [SN00], [SJ02] und [Sei02].

Hier finden sich auch spezielle Diagramme und graphische Konzepte zur Beschrei-bung von Ablaufen. Wir gehen darauf jedoch nicht weiter ein.

18. Marz 2014 167


5.4. Zusammenhang zwischen Schnittstellenverhalten und

Ablaufen

Stromverarbeitende Funktionen beschreiben das Verhalten von Systemkomponentenals Abbildungen von Eingabedatenstromen auf Ausgabedatenstrome. Jedes Paar (x,y) von Eingabestromen x und Ausgabestromen y beschreibt eine mogliche Syste-meingabe x und die dadurch stimulierte Systemausgabe y.

Tatsachlich wird naturlich nicht zuerst die gesamte Eingabe bestimmt und an-schließend die gesamte Ausgabe festgelegt. Vielmehr werden Ein- und Ausgabestuckweise in der Interaktion zwischen dem System und seiner Umgebung bestimmt.Diese Interaktion konnen wir explizit machen, indem wir die Eingaben in x und dieAusgaben in y in einem Strom zusammenmischen. Wir erhalten dadurch einen Ab-lauf von Ein- und Ausgaben. Die Kausalitat zwischen Ein- und Ausgabe lasst sichdurch die Monotonie der Funktion bestimmen.

Beispiel 5.6: Ablaufe einer stromverarbeitenden FunktionStromverarbeitenden Funktionen lassen sich ebenfalls Aktionsstrukturen als Ablaufezuordnen. Wir betrachten die Funktion

f : Stream Nat→ Stream Nat

spezifiziert durch die Gleichung:

f(x) = (first(x) + first(rest(x))) & f(rest(rest(x)))

Der Eingabestrom

x = 0 & 1 & 2 & 3 & 4 & . . .

fuhrt auf den Ausgabestrom y = f(x) gegeben durch

y = 1 & 5 & 9 & 13

Die Ablaufe sind allesamt Sequentialisierungen des Prozesses, der in Abb. 5.6 ange-geben ist. Hier sind Eingaben und Ausgaben als Zahlen dargestellt.

0

951

7654321

13

x =

y =

Abb. 5.6.: Ablaufstruktur

Wir nennen einen sequentiellen Ablauf einer stromverarbeitenden Funktion respon-siv, wenn alle Ausgaben zum fruhestmoglichen Zeitpunkt in dem Strom auftreten.responsiver

Ablauf Der responsive Ablauf mit Eingabe x und Ausgabe y ist gegeben durch den Strom

168 18. Marz 2014

5.5. Ablaufe verteilter kommunizierender Systeme

x:0 − x:1 − y:1 − x:2 − x:3 − y:5 − x:4 − x: 5 − y:9 − x:6 − x: 7 − y:13 − . . .

2

Fur jede stromverarbeitende Funktion f lasst sich insbesondere mit jeder Eingabewieder eine Menge M von Stromen verbinden, die eine Mischung aus Ausgabe undEingabe bilden. Der Strom s ist ein Ablauf von f zu Eingabe x, wenn folgende Aussagegilt: Es existiert ein Boolescher Strom z (das Orakel) mit

(1) Der Ablauf ist Mischung aus Ein- und Ausgabe

pfilter(z, s) = x ∧ nfilter(z, s) = f(x)

(2) Die Ausgabe kommt nach der erforderlichen Eingabe

∀ s′ : s′ v s⇒ nfilter(z, s′) v f(pfilter(z, s′))

Die Bedingung (1) fuhrt auf Strome, in denen Ein- und Ausgabestrome gemischtsind, die Ausgabewerte jedoch so fruh, wie nach Regeln (1) und (2) nur moglich,auftreten. Auf diese Weise konnen wir stromverarbeitende Funktionen als Mengenvon Ablaufen darstellen.

Wir konnen das Verhalten eines Datenflussknoten somit auch durch die Mengeseiner Spuren beschreiben.

5.5. Ablaufe verteilter kommunizierender Systeme

Eine sehr hilfreiche und anschauliche Darstellung der Ablaufe in verteilten Syste-men, die Nachrichten austauschen, sind Interaktionsdiagramme (Message SequenceCharts, Event Traces). Interaktions-

diagrammeMSCs

Ein Interaktionsdiagramm beschreibt einen Ablauf eines Systems durch die Anga-be der Nachrichten, die zwischen den Komponenten ausgetauscht werden. Abb. 5.7zeigt schematisch ein Interaktionsdiagramm fur ein System mit den KomponentenK1, . . . , Kn. Fur jede Komponente versinnbildlicht die vertikale Linie den Zeitfluss vonoben nach unten. Horizontale Pfeile, markiert mit c: m, stellen den Nachrichtenaus-tausch der Nachricht m auf dem Kanal c zwischen den entsprechenden Komponen-ten dar. Pfeile ohne Quelle oder Ziel symbolisieren mit der Umgebung verbundeneKommunikationsschritte.

Ein Interaktionsdiagramm beschreibt in graphischer Darstellung einen Prozess.Sind schematische Interaktionsdiagramme gegeben, so konnen wir diese auf Formelnin Gestalt von Gleichungen abbilden.

Beispiel 5.7: Ableitung von Gleichungen aus InteraktionsdiagrammAbb. 5.8 zeigt zwei Szenarien fur Interaktionen einer Ubertragungskomponente TR.

18. Marz 2014 169


K1 K2 Kn…

c1 : m1c2 : m2

c3 : m3

c4 : m4

c5 : m5

…

…

Abb. 5.7.: Interaktionsdiagramme fur die Komponenten K1,K2, . . . ,Kn

Sender TR Receiver

a : m

b : ready

c : Y

b : m

d : Y

Sender TR Receiver

a : m

b : ready

c : N

d : N

Abb. 5.8.: Zwei Interaktionsdiagramme fur die Komponente TR

Von den zwei Beispielen fur Interaktionsdiagramme in Abb. 5.8 konnen wir folgendeGleichungen fur die stromverarbeitende Funktion fTR der involvierten KomponenteTR ableiten:

(1) fTR(〈a : m〉) = 〈b : ready〉

(2) fTR(〈a : m〉〈c : Y〉 x) = 〈b : ready〉〈d : Y〉〈b : m〉 fTR(x)

(3) fTR(〈a : m〉〈c : N〉 x) = 〈b : ready〉〈d : N〉 fTR(x)

Die Gleichung (1) ergibt sich aus beiden Diagrammen, die Gleichung (2) aus dem

170 18. Marz 2014

5.6. Historische Bemerkungen zur Ablaufsicht

linken Diagramm und (3) aus dem rechten Diagramm. 2

Auf diese Weise konnen wir Interaktionsdiagramme als eine Form der logischen Spe-zifikation durch Gleichungen fur stromverarbeitende Funktionen auffassen. Schwie-riger wird die Behandlung von Nichtdeterminismus, da dann kein einfaches Konzeptvon Konsistenz existiert.

Beispiel 5.8: Nichtdeterminismus und Unterspezifikation in MSCsDie syntaktische Schnittstelle fur die Komponente UM ist in Abb. 5.9 gegeben. Abb.5.10 gibt zwei Interaktionsdiagramme wieder.

UM

a : M

b : M c : {ack, fim}

Abb. 5.9.: Syntaktische Schnittstelle der Komponente UM

Von den zwei Beispielen fur Interaktionsdiagramme in Abb. 5.10 konnen wir folgendeGleichungen fur die involvierten Komponente fUM ableiten:

fUM(〈a : m〉 x) = 〈c : ack〉〈b : m〉 fUM(x)

∨fUM(〈a : m〉 x) = 〈c : fim〉 fUM(x)

Diese Gleichungen sind durch ein logisches”oder“ verknupft, da sie zwei alternative

Verhaltensweisen der Komponenten auf den gleichen Inputstimulus beschreiben. 2

Interaktionsdiagramme erlauben eine sehr anschauliche Darstellung der Interaktionzwischen den Komponenten eines Systems. Dies ist fur praktische Anwendungenwichtig und hilfreich. Allerdings besteht bei komplizierten Systemen die Gefahr,dass eine große Zahl von Interaktionsdiagrammen notig ist, um das Systemverhaltenumfassend zu beschreiben. Dann wird die Beschreibung oft unubersichtlich.

5.6. Historische Bemerkungen zur Ablaufsicht

Schon einer der fruhen Ansatze zur Modellierung verteilter vernetzter Systeme, diePetri-Netze, stellen den Begriff der Ablaufe und des Prozesses (in Petri-Netz Jargon

18. Marz 2014 171


Sender UM Receiver

a : m

b : mc : ack

Sender UM Receiver

a : m

c : fim

Abb. 5.10.: Zwei Interaktionsdiagramme fur die Komponente UM

”Occurrence-Net“) zentral in den Mittelpunkt (vgl. [Rei90]). Fur Petri-Netze werden

so genannte Occurrence-Netze betrachtet, die im Wesentlichen der Entfaltung zuPetri-Netzen in unendliche Ablaufstrukturen entsprechen.

In Publikationen finden sich anfangs eher informelle Beschreibungen von Ablaufen,in denen skizzenhaft dargestellt wird, wie die einzelnen Aktionen des Systems zu-einander in Beziehung zu setzen sind. Spater wird erkannt, wie stark diese Artder Beschreibung, gerade fur betriebswirtschaftliche Prozesse nutzlich ist. Beschrei-bungsmethoden wie ARIS von Scheer (vgl. [SN00], [SJ02] und [Sei02]) stellen dieProzessmodellierung in den Mittelpunkt. Parallel dazu entwickeln sich eine ganzeReihe von Ansatzen, in denen Prozesse direkt als Ablaufe von Systemen darstell-bar sind. Es gibt dafur eine Reihe von Prozessbeschreibungssprachen (siehe auch[Thu04]).

Auch die Modellierungssprache UML unterstutzt die Idee der Prozessbeschrei-bung. Dabei sind naturlich geeignete Abstraktionsmittel besonders gefragt. Ein vielversprechender Ansatz sind die so genannten Interaktionsdiagramme oder

”Message

Sequence Charts“, die sich im Umfeld von SDL in der Telekommunikation entwickelthaben. Diese wurden auch in die UML unter dem Stichwort

”Interaktionsdiagram-

me“ oder”Sequenzdiagramme“ ubernommen. Sie sind ein sehr anschauliches und

nutzliches Mittel, um das Zusammenwirken von Systemteilen im Sinne des Prozes-ses der Kommunikationsaktionen zu beschreiben. Die formale Fundierung und dersystematische methodische Gebrauch der Interaktionsdiagramme in das Vorgehenbei der Systementwicklung ist allerdings noch nicht vollig abgeschlossen.

172 18. Marz 2014

6. Nachrichtensynchrone Systeme

Bisher haben wir primar interaktive Systeme mit asynchroner (gepufferter) Kommu-nikation betrachtet. Dies bedeutet, dass vom Sender Nachrichten unabhangig vonder Frage, ob der Empfanger empfangsbereit ist, gesendet werden. Dies hat denVorteil dass die Systemkomponenten weitgehend entkoppelt ablaufen konnen. So-mit wird damit die Struktur in uber Netzen verteilten Teilsysteme zutreffend erfolgt.Allerdings mussen Nachrichten, zu deren Empfang der Empfanger noch nicht bereitist, gepuffert werden (Briefkastenprinzip).

Nun betrachten wir Komponenten, die in Hinblick auf den Nachrichtenaustauschsynchron interagieren. Fur sie gilt, dass eine Sendeaktion nur dann stattfinden kann,wenn ein Empfanger empfangsbereit ist. Damit wird eine Pufferung von gesende-ten aber noch nicht empfangenen Nachrichten unnotig. Daruber hinaus kann dieAuswahl eines Empfangers zu einem kommunikationswilligen Sender uber die Emp-fangsbereitschaft des Empfangers (und umgekehrt) erfolgen (Telefonprinzip im Call-Center).

Ein sehr spezieller Formalismus fur die Programmierung solcher synchron kom-munizierender Systeme ist ein Formalismus mit Namen CSP (Communicating Se-quential Processes). CSP entspricht einer abstrakten Programmiersprache fur syn- CSP

chron kommunizierende Systeme. CSP wurde von C.A.R. Hoare vorgeschlagen (vgl.[Hoa78]) und hat in den 30 Jahren seitdem viel Aufmerksamkeit auf sich gezogenund umfangreiche Forschungsarbeiten stimuliert. CSP hat einen praktischen Nieder-schlag in der Programmiersprache OCCAM gefunden (vgl. [Hoa85b] und [Hoa85a]).Ein sehr ahnlicher, allerdings starker auf theoretische Fragestellungen ausgerichteterAnsatz wurde von R. Milner unter dem Stichwort CCS (Calculus of CommunicatingSystems, vgl. [Mil80]) entwickelt.

6.1. Nachrichtensynchrone Komposition von Automaten

Zunachst definieren wir das Konzept des synchronen Automaten. Wir betrachtenfur i = 1, 2 zwei Automaten mit markierten Ubergangen der Form

∆i : Σi × Ai → ℘(Σi)

Dabei sei eine Menge Σei ⊆ Σi von Endzustanden ausgezeichnet, in denen ∆i(σ, a) =

∅ fur e ∈ Σei und alle a ∈ Ai gilt konnen wir einen neuen Automaten durch synchrone

Komposition wie folgt konstruieren.

∆ = ∆1 9 ∆2 : (Σ1 × Σ2)× A→ ℘(Σi)

18. Marz 2014 173

Kapitel 6. Nachrichtensynchrone Systeme

Dabei treffen wir folgende Annahme fur die Aktionsmengen A1 und A2:

(1) A1 ∩ A2 = ∅ die Aktionsmengen beider Automaten enthalten keine ge-meinsame Aktionen.

(2) Ai = Asi ∪ Aa

i Es existiert fur die Aktionsmengen beider Automaten einedisjunkte Zerlegung in Mengen synchroner und asynchro-ner Aktionen.

(3) Es existiert ein Pradikat h : As1 × As

2 → B, welches festlegt, welche der syn-chronen Aktionen gemeinsam (

”synchron“) ausgefuhrt werden konnen bzw.

mussen.

Wir definieren die Menge der Aktionen fur ∆:

A = Aa1 ∪ Aa2 ∪ (As1 × As

2)

Die Grundidee ist, dass die synchronen Aktionen durch die Automaten in dem zu-sammengesetzten Automaten gemeinsam ausgefuhrt werden (mussen).

∆((σ1, σ2),a) =

asynchr.Anteil ∪

{(σ′1, σ2) : a ∈ Aa1 ∧ σ′1 ∈ ∆1(σ1,a)}

{(σ1, σ′2) : a ∈ Aa

2 ∧ σ′2 ∈ ∆2(σ2,a)}

synchr.Anteil

∪ {(σ′1, σ′2) : ∃a1 ∈ As1,a2 ∈ As

2 :a = (a1,a2) ∧ h(a1,a2) ∧σ′1 ∈ ∆1(σ1,a1) ∧ σ′2 ∈ ∆2(σ2,a2)}

Der zusammengesetzte Automat kann asynchrone Ubergange vollziehen, und zwarunabhangig fur jeweils einen der gegebenen Automaten, oder aber synchrone Uber-gange gemeinsam durchfuhren. Synchrone Ubergange bestehen aus zwei zusammen-gehorigen Aktionen beider Automaten und den entsprechenden Ubergangen fur bei-de Automaten.

Kann in einem Zustand keiner der beiden Automaten einen asynchronen Uber-gang ausfuhren und passen die in dem Zustand moglichen synchronen Ubergangenicht zusammen und sind auch beide Automaten nicht in einem Endzustand, sobefindet sich der zusammengesetzte Automat in einer Verklemmung.

Beispiel 6.1: Nachrichtensynchrone Komposition von AutomatenSiehe Abb. 6.1. 2

Wir geben ein einfaches Beispiel fur die synchrone Komposition von Automaten.

Beispiel 6.2: Synchrone Komposition von Erzeuger/VerbraucherWir betrachten die Automaten in Abb. 6.2. Diese zeigt zwei Automaten producer

174 18. Marz 2014

6.2. Syntax von CSP

a

b

d

e

c

c

Automat1

Automat2

Rendezvousasynchrone

synchron

Abb. 6.1.: Nachrichtensynchrone Komposition

und consumer, sowie deren synchrone Komposition. Dabei sind send und receivesynchron auszufuhrende Aktionen.

Hier definieren wir, dass fur die Automaten die Aktion produce sowie consumeasynchron, hingegen die Aktion send und die Aktion receive synchron sind, und

h(send, receive) = true

gilt. 2

Im obigen Beispiel haben wir nur zwei synchrone Aktionen betrachtet, sowie Auto-maten die genau zusammenpassen. Schwieriger wird das Zusammensetzen der Au-tomaten, wenn es mehrere synchrone Aktionen gibt, die die Automaten ausfuhrenkonnen. Denn mussen sich die Automaten gegebenfalls

”verstandigen“, welche der

Moglichkeiten synchrone Aktionen auszufuhren letztendlich gewahlt wird.

6.2. Syntax von CSP

Wir betrachten die Sprache von Agenten in CSP, in der folgende Anweisungsmusterauftreten (in einer Erweiterung der Sprache der Guarded Commands von Dijkstraum Kommunikationsanweisungen):

nop leere Anweisungabort nichtterminierende Anweisung

18. Marz 2014 175


production wait_for_consumer

producer:

wait_for_producerconsumption

produce

send

consume

receive

consumer:

producer consumer:

(production, consumption) (wait, wait)

(wait, consumption)

(production, wait)

produce consume

consume produce

(send, receive)

Abb. 6.2.: Automaten producer, consumer und producer 9 consumer

x := E Zuweisungc ? v Eingabeereignis (bei Hoare: receive)c ! E Ausgabeereignis (bei Hoare: send)S ; S′ Sequenzielle Komposition von Anweisungenif . . . [] Gi then Si [] . . . fi Bewachte Anweisung

(bei Hoare: Guarded Command)S ‖ S′ Parallele Komposition

(Nebenlaufigkeit, Parallelitat)do . . . [] Gi then Si [] . . . od Wiederholungsanweisung

Dabei konnen die Bedingungen Gi von bewachten Anweisungen und Wiederholungs-anweisungen folgende syntaktische Form annehmen (Ci sei ein Boolescher Ausdruckund c sei ein Kanalname)

Gi ≡ Ci Wachter (ohne Kommunikation)Gi ≡ Ci : c ? v bewachte Kommunikation: EingabeGi ≡ Ci : c ! E bewachte Ausgabe

176 18. Marz 2014

6.2. Syntax von CSP

Wir setzen folgende syntaktische Nebenbedingung fur die parallele KompositionS ‖ S′ zweier Anweisungen S und S′ voraus: Jede Variable v tritt hochstens in Soder in S′ auf, das heißt, es gibt in CSP keine gemeinsamen Variablen, sondern nursynchrone Kommunikation uber Kanale. Die Kooperation findet ausschließlich uberNachrichtenaustausch statt.

Ferner setzen wir die folgende Menge (Sorte) fur die Menge der Kanalnamenvoraus:

Channel ID

CSP erlaubt die Formulierung von Programmen mit Kommunikationsanweisungennd synchroner Kommunikation.

Achtung: Kanale enthalten hier keinen Puffern, es werden dort keine Nachrich-ten zwischengespeichert. Der Nachrichtenaustausch erfolgt synchron durch direkteUbergabe (

”Handshake“) zwischen Sender und Empfanger (

”Rendezvous“).

Beispiel 6.3: Programme in CSP

(1) Puffer in CSPDa in CSP keine Kanale mit impliziten Puffern (wie bei asynchroner Kom-munikation) verwendet werden, mussen Puffer explizit formuliert werden. Einendlicher Puffer mit maximaler Lange bound wird in CSP wir folgt beschrie-ben:

P (in: Chan Data, out: Chan Data) ={q: var Queue Data;

x: var Data;q := 〈〉;do ¬isempty(q): out ! first(q) then q := rest(q)[] q < bound: in ? x then q := enq(q, x)od }

Der Puffer ist bereit, Eingaben entgegen zu nehmen, solange er seine maxi-male Lange nicht erreicht hat. Nur wenn der Puffer nicht leer ist, ist er bereitAusgaben zu produzieren.

(2) Verkaufsautomat in CSPEinen einfachen Verkaufsautomat fur Waren konnen wir in CSP wie folgt be-schreiben. Der Automat benutz folgende Kanale:

wahl, warenaus: Chan Waregeldein, geldaus: Chan Natausgabe, ruckgabe: Chan Signal

18. Marz 2014 177


Hier ist Signal die Sorte mit nur einem Element req. Dadurch konnen wir dasDrucken eines Knopfes darstellen.

b: var Bool; g,y: var Nat; x: var Ware; z: var Signal;do true then

wahl ? x;b, g := true, 0;do b ∧ g < preis(x): geldein ? y then g := g + y[] b ∧ g ≥ preis(x): ausgabe ? z then warenaus ! x; b := false[] b ∧ g < preis(x): ruckgabe ? z then geldaus ! g; b := falseod

od

Stimmt der aufaddierte Geldbetrag mit dem Preis uberein, erfolgt die Waren-ausgabe. Uberbezahlte Betrage gehen verloren.

2

Es wird in CSP angenommen, dass jeder Nachrichtenaustausch – bestehend auszusammengehorigem Senden und Empfangen – eine unteilbare Aktion des Systemsdarstellt. Ist aufgrund nicht zusammenpassender Aktionen der parallel ablaufendenProgramme kein Nachrichtenaustausch moglich, so fuhrt dies auf eine Verklemmung.So fuhrt etwa das Programm

(x ! 1; y ? v) ‖ (y ! 2; x ? w)

auf eine Verklemmung, da das linke Programm auf einer Ausgabe auf Kanal x, dasrechte auf einer Ausgabe auf Kanal y besteht.

Achtung: Bei asynchroner Kommunikation fuhrt das oben beschriebene Pro-gramm hingegen auf keine Verklemmung. Das Senden ist fur beide Programmemoglich, da die Nachrichten zwischengepuffert werden. Eine Umsetzung in einepradikative Spezifikation zeigt das.

6.3. Operationelle Semantik fur CSP

Wir geben eine operationelle Semantik fur CSP an. Genauer gesagt beschreiben wirCSP-Programme als Zustandsmaschinen. Dazu definieren wir eine Zustandsuber-gangsrelation auf Paaren (t, σ) (genannt Konfiguration, die einem Zustand ent-spricht), wobei t ein Agent ist und σ ein Datenzustand ist. Das Paar (t, σ) definiertden Zustand der Berechnung. Sei

CSP

178 18. Marz 2014

6.3. Operationelle Semantik fur CSP

die Menge der CSP-Programme und Σ die Menge der Zustande (Belegung der Pro-grammvariablen) eines CSP-Programms. Wir definieren zur Beschreibung der ope-rationellen Semantik eine Zustandsubergangsrelation

→ ⊆ (CSP× Σ)× A× (CSP× Σ)

Hier ist A die Menge der Kommunikationsaktionen, die wie folgt definiert sei:

A = {x!d : x ∈ Channel Id∧d ∈ Wert}∪{x?d : x} ∈ Channel Id∧d ∈ Wert}∪{ε}

Der Ubergang tε→ t′ heißt auch stiller Ubergang. Statt der Ubergange mit leerer Stiller

UbergangAnweisung (leerer Aktion)

tε→ t′

schreiben wir einfach

t → t′.

Wir setzen fur jeden Zustand σ ∈ State eine Auswertungsfunktion fur Ausdruckevoraus

Valσ : Exp→ Value

Folgende Regeln beschreiben die operationelle Semantik durch eine Axiomatisierungder Ubergangsfunktion:

Empfangen:

(x?v, σ)x?d→ (nop, σ[d/v])

Senden:

Valσ[E] = d

(x!E, σ)x!d→ (nop, σ)

Sequentielle Komposition:

(S, σ)m→ (S′, σ′)

(S; S′′, σ)m→ (S′; S′′, σ′)

Sequentielle Komposition mit nop:

(nop; S, σ)ε→ (S, σ)

Bewachte Anweisung mit Kommunikation:

Valσ[Ci] = true (Mi, σ)m→ (nop, σ′)

(if . . . []Ci : Mi then Si[] . . . fi, σ)m→ (Si, σ′)

18. Marz 2014 179


Bewachte Anweisung ohne Kommunikation:

Valσ[Ci] = true

(if . . . []Ci then Si[] . . . fi, σ)→ (Si, σ′)

Parallele Anweisung:

(a) unabhangige Aktionen:

(S1, σ)m→ (S′1, σ

′)

(S1 ‖ S2, σ)m→ (S′1 ‖ S2, σ

′)

(S2 ‖ S1, σ)m→ (S2 ‖ S′1, σ

′)

(b) interne synchrone Kommunikation:

(S1, σ)x!d→ (S′1, σ), (S2, σ)

x?d→ (S′2, σ′)

(S1 ‖ S2, σ)ε→ (S′1 ‖ S′2, σ

′)

(S2 ‖ S1, σ)ε→ (S′2 ‖ S′1, σ

′)

(c) Terminierung eines Zweiges in der parallelen Komposition

(S ‖ nop, σ)ε→ (S, σ)

(nop ‖ S, σ)ε→ (S, σ)

Wiederholung und Zuweisung sind wie gehabt fur sequentielle Programme definiert.

Wiederholung: Sei

DO = do . . . [] Gi then Si [] . . . od

Dann gilt

(DO, σ)→ (if . . . [] Gi then Sij; DO [] . . . [] ¬C1 ∧ · · · ∧ Cn then nop fi, σ)

wobei Ci jeweils der Boolesche Ausdruck im Wachter Gi sei.

Zuweisung

(x := E, σ)→ (nop, σ[valσ[E]/x])

Fur einen Zustand σ ∈ Σe sagen wir, dass der Agent t ( 6= nop) in einer Verklemmungist, falls keine Aktion m, Nachfolgeprogramm t′ und Zustand σ′ existieren mitVerklemmung

(t, σ)m→ (t′, σ′)

Die markierte Ersetzungsrelation laßt sich durch folgende Regeln auf Ubergangemarkiert durch Sequenzen von Aktionen uber M\{ε} erweitern (sei ε jetzt die leereSequenz):

180 18. Marz 2014

6.4. Bereitschaft und Verweigerung

(t, σ)ε⇒ (t′, σ′) falls (t, σ)

ε→ (t′, σ′)

(t, σ)〈m〉⇒ (t′, σ′) falls (t, σ)

m→ (t′, σ′)

(t, σ)s◦s′⇒ (t′, σ′) falls (t, σ)

s→ (t′, σ′) und (t′, σ′)s′→ (t′′, σ′′)

Wir sprechen vom Ablaufpfad s fur die Konfiguration (t, σ), falls gilt: Ablaufpfad

∃ t′, σ′ : (t, σ)s⇒ (t′, σ′)

Es lassen sich auch unendliche Ablaufe betrachten: Eine endliche oder unendlicheSequenz von Kommunikationsaktionen heißt vollstandiger Ablauf zur Konfiguration(t0, σ0) falls gilt

(1) ∃ σ′ : (t0, σ0)s⇒ (nop, σ)

(2) Es existieren ti, σi, si, fur i > 0 mit

(ti−1, σi−1)s⇒ (ti, σi) und s = sup{s0 . . . si : i ∈ N}

Ebenso lasst sich fur eine Konfiguration (t, σ) der Baum (genannt Synchronisati-onsbaum) der Ubergange angeben (vgl. Abb. 6.3). Der Synchronisationsbaum kann Synchroni-

sationsbaumunendliche Pfade enthalten, dabei seien sb(t(i), σ(i)) die Synchronisationsbaume fur(t(i), σ(i)).

Die operationelle Sematik ordnet jeder Konfiguration eine Zustandsmaschine zu,die die Konfiguration als Anfangszustand enthalt.

•m1 mn

… sb(t(n), (n))sb(t(1), (1))

Abb. 6.3.: Synchronisationsbaum fur sb(t, σ)

Dabei gelte in Abb. 6.3, dass stets (t, σ)mi⇒ (t(i), σ(i)) gilt und dass die Ubergange

fur i = 1, . . . , n die einzige Ubergange sind.


Um das Schnittstellenverhalten eines CSP-Programms in einem vorgegebenen Zu-stand zu beschreiben, verwenden wir wieder Mengen von Ablaufen (engl. traces).Ein Ablauf ist ein Strom uber der Menge A\{ε} von Kommunikationsaktionen. Wie- Ablauf

(trace)der konnen wir zwischen partiellen (d.h. endlichen) und vollstandigen Ablaufe un-terscheiden. Zusatzlich wird fur endliche konvergierende Kommunikationsspuren die

18. Marz 2014 181


Angabe eines Endzustandes σ′ notwendig, um das Verhalten eines CSP-Programmsin beliebigen Umgebungen, die wieder durch CSP-Programme beschrieben sind, er-mitteln zu konnen.

Allerdings ist durch die Angabe der Menge der Ablaufe das Verhalten eines CSP-Agenten noch nicht hinreichend beschrieben. Dies wird durch folgendes klassischesBeispiel deutlich:

t1 ≡ if true; x!1 then S1

[] true; y!2 then S2

fit2 ≡ if true then x!1; S1

[] true then y!2; S2

fi

Betrachten wir namlich das Programm

pi ≡ ti ‖ x?v

so kann p2 auf eine Verklemmung fuhren, wohingegen p1 verklemmungsfrei ist (fallsS1 verklemmungsfrei ist). Die Agenten t1 und t2 besitzen jedoch identische Mengenvon Ablaufen (engl.

”traces“).

Ein wesentlicher Punkt bei synchronem Nachrichtenaustausch ist folglich die Fra-ge, wann entschieden wird, zu welchen Kommunikationsaktionen eine CSP-Komponentebereit ist. Betrachten wir die CSP-Terme t1 und t2. Wir erhalten fur beliebige n ∈ N

(t1, σ)x!1→ (S1, σ)

und

(t1, σ)y!2→ (S2, σ)

Fur t2 erhalten wir

(t2, σ)→ (x!1; S1, σ)

und

(t2, σ)→ (y!2; S2, σ)

Die Konfiguration (t1, σ) ist sowohl zu der Aktion x!1 als auch zur Aktion y!2 be-reit. Die Konfiguration (t2, σ) ist nach einem ε-Schritt entweder zur Aktion x!1 oderaber zur Aktion y!2 bereit. Diese Form der Bereitschaft konnen wir in Synchronisa-tionsbaumen ausdrucken. Jede Konfiguration bekommt einen (in der Regel unendli-chen) Synchronisationsbaum. Eine Konfiguration K ist in unserem Ansatz entwederzu ε-Ubergangen oder zu Kommunikationsaktionen bereit. Aufeinanderfolgende ε-Ubergange fassen wir zusammen (siehe Abb. 6.4)

182 18. Marz 2014


…

s1

m1 mk

…

sm…

…

s1

m1 mk …

sm…

geht über in

Abb. 6.4.: Normalisierung der Synchronisationsbaume

x ! 1

sb(t1, ): •

y ! 2

x ! 1

sb(t2, ): •

y ! 2εε

ε ε

Abb. 6.5.: Synchronisationsbaume fur t1 und t2

Wir erhalten normalisierte Synchronisationsbaume. Abb. 6.5 zeigt die Synchroni-sationsbaume fur (t1, σ) und (t2, σ). Hier ist der Unterschied zwischen t1 und t2

deutlich zu erkennen. Wir kommen darauf zuruck.

Dies zeigt, dass die Menge der Spuren nicht genugend Information enthalt, um dasVerhalten eines synchron kommunizierenden Programmes in gegebener Umgebungeindeutig vorherzusagen. Damit wird deutlich, dass die Trace-Aquivalenz bzgl. derKommunikation-Traces auf CSP keine Kongruenzrelation in Hinblick auf die paral-lele Komposition ist.

Achtung: Die Trace-Aquivalenz der CSP-Ausdrucke wie der synchronen Au-tomaten reicht nicht aus, um Deadlocks in zusammengesetzten Automaten festzu-stellen. Fur diese Art von Automaten ist die Trace-Aquivalenz folglich keine Kon-gruenzrelation.

Um das Verhalten eines Agenten insbesondere in Bezug auf Deadlocksituationenbei Abarbeitung in der parallelen Komposition im Zusammenspiel mit anderen Pro-grammen bestimmen zu konnen, ist es erforderlich, nicht nur die Menge der Ablaufedes Agenten zu kennen, sondern zu jedem (unvollstandigem) Ablauf ist die Kenntnis

18. Marz 2014 183


der Bereitschaftsmengen erforderlich. Eine Menge

R ⊆⋃

x ∈ Kanalname

{x!, x?}

heißt Bereitschaftsmenge (fur einen Ablauf) falls der gegebene Agent (nach Aus-Bereitschafts-menge fuhrung der in dem Ablauf angegebenen Kommunikationsaktionen) zu den in R

angegebenen Aktionen fahig ist.Formal modellieren wir dies wie folgt: Seien folgende Definitionen gegeben:

s endlicher Ablauf (s ∈ (M\{ε})∗)(t, σ) KonfigurationR ⊆ M\{ε}

R heißt Bereitschaftsmenge fur die Konfiguration (t, σ) und den Ablauf s, falls gilt:es existiert ein Paar (t′, σ′), so dass gilt:

(t, σ)s⇒ (t′, σ′) ∧ (∃t′′, σ′′ : (t′, σ′)

m→ (t′′, σ′′))⇔ m ∈ M

Fur einen unvollstandigen Ablauf s eines nichtdeterministischen Agenten konnenviele unterschiedliche Bereitschaftsmengen existieren. Dann sind wir nach der Be-obachtung des Ablaufs nur sicher, dass ein Agent ein Kommunikationsangebot (zurKommunikation) annimmt, wenn das Angebot mit jeder der Bereitschaftsmengeneinen nichtleeren Durchschnitt besitzt.

Eine leere Bereitschaftsmenge charakterisiert die Situation der Verklemmung. Manbeachte, dass wir Konfigurationen (t′, σ′) in obiger Definition mit ε−Transitionennicht betrachten. Es sind nur Konfigurationen von Interesse, in denen keine stillenTransitionen mehr moglich sind. Ein CSP-Programm, das nach einem bestimmtenAblauf keine solche Konfiguration erreicht, besitzt keine Bereitschaftsmengen.

Jede Menge, die mit mindestens einer Bereitschaftsmenge einen leeren Durch-schnitt besitzt, heißt Verweigerungsmenge (engl. refusal set). Jede Teilmenge ei-Verwei-

gerungs-menge(refusal set)

ner Verweigerungsmenge ist selbst wieder Verweigerungsmenge. Es genugt auch dieVerweigerungsmengen zu kennen, um die Verklemmungseigenschaften eines Agentenbeschreiben zu konnen. Sei

A =⋃

x ∈ Kanalname

{x!, x?}

Wir erhalten folgende semantische Darstellung des Verhaltens s eines Agenten

Σ→ BEHAVIOR

wobei

BEHAVIOR = {B ⊆ (M∗ × P(A)) ∪ (M∗ × Σ⊥):∀ (s, R) ∈ B:(1) ∀ s′ v s: ∃ R′: (s′, R′) ∈ B(2) ∀ X ⊆ A: ∀ X ⊆ Y: (s, Y) ∈ B }

184 18. Marz 2014

6.5. Historische Bemerkungen zur Modellierung nachrichtensynchroner Systeme

BEHAVIOR kann als denotationelles semantisches Modell fur die Sprache CSP ver-wendet werden. Dieses Modell kann auch als Grundlage fur Spezifikationen dienen.allerdings sind diese Spezifikationen oft schwierig und fehleranfallig.

6.5. Historische Bemerkungen zur Modellierung

nachrichtensynchroner Systeme

Die Idee der Modellierung von kommunizierenden Systemen durch nachrichtensyn-chrone Kommunikation entstand gleichzeitig in mehreren Forschungsansatzen. Ammeisten Beachtung hat diese Idee durch die Publikationen von C.A.R. Hoare in Com-munication of the ACM1 unter dem Stichwort

”Communicating Sequential Proces-

ses“ (vgl. [Hoa78]) erfahren und durch die fruhen theoretischen Arbeiten Robin Mil-ner zum Thema CCS (Calculus of Communicating Systems, vgl. [Mil80]). Beiden Ar-beiten gemein ist der Versuch, ein sehr grundlegendes Verstandnis uber verteilte Sys-teme zu schaffen unter besonderer Betonung der Kommunikation und Interaktion.In beiden Fallen entstanden auf den ersten Blick sehr eingangige Kommunikations-und Kooperationskonzepte, gepragt von der Vorstellung, dass nebenlaufige Syste-me zu bestimmten Zeitpunkten sich auf gemeinsame Aktionen verstandigen, die siegleichzeitig gemeinsam durchfuhren, beispielsweise den Austausch von Nachrichtenoder das gemeinsame Arbeiten auf gemeinsamen Speichern. Ahnliche Ideen flossenbereits in die ersten Arbeiten fur die Programmiersprache ADA (vgl. [Nag99]) ein,die Ende der Siebziger, Anfang der Achtziger Jahre vom amerikanischen Verteidi-gungsministerium in Auftrag gegeben wurde.

In seiner Publikation in ACM [Hoa78] zeigt Hoare in einer ganzen Reihe von Bei-spielen, wie elegant bestimmte Losungen in dem von ihm vorgeschlagenen Ansatzformuliert werden konnen. Allerdings erweist sich die formale Fundierung des Ansat-zes nach ersten theoretischen Arbeiten durchaus als sperrig. Das Ziel von Hoare eindenotationelles Modell zu schaffen – das heißt ein Modell, das eine modularen Defini-tion des Verhaltens synchroner Systeme ermoglicht, zeigt, dass es schwierig ist, einenSchnittstellenbegriff fur Systeme mit synchronem Nachrichtenaustausch zu identifi-zieren. Die parallel dazu laufenden Arbeiten in Edinburgh auf Basis der Ideen vonRobin Milner zeigen ahnliche Schwierigkeiten bei dem Versuch, eine Kongruenzre-lation auch der Termsprache von CCS zu definieren, was im Grunde genommenauf die gleiche Zielsetzung wie eine denotationelle Semantik hinauslauft. Entgegenerster Vermutungen ist die Spuraquivalenz (trace equivalence) keine Kongruenz-struktur wie das beruhmte, im Text zitierte Beispiel, deutlich macht. Es wird dieviel kompliziertere Kongruenzrelation der Bisimulation (siehe spater) erforderlich.

Gleichzeitig zu den Arbeiten in Edinburgh arbeitet Hoare an dem denotationellenModell, das er in der ersten Halfte der Achtziger Jahre schließlich zufriedenstellend

1ACM (Association of Computing Machinery) – alteste und bedeutenste Computerwissenschafts-Vereinigung.

18. Marz 2014 185


konstruieren kann (vgl. [Hoa85a]). Er definiert ein denotationelles Modell unter demStichpunkt der Verweigerungsmengen, in denen in der Tat eine modulare Beschrei-bung von Systemen unterstutzt wird. Allerdings ist dieses Modell komplizierter alses auf Grund der eingangigen sprachlichen Ansatze, von denen Hoare und Milnerausgegangen sind, zu vermuten ware.

Die Idee der Bisimulation lost zwar eine Fulle wissenschaftlicher Arbeiten aus,in denen unterschiedliche Bisimulationsrelationen untersucht werden und es entste-he Programme, die fur gewisse endliche Systeme die Bisimulationsaquivalenz uber-prufen. Allerdings fuhrt keine dieser Arbeiten zu praktisch brauchbaren, relevan-ten Ergebnissen. Lediglich gewisse algorithmische Uberprufungen der Bisimulati-onsaquivalenz der Modelchecking scheinen praktisch interessant (siehe [CGP99]).Typischerweise finden sich in den eher praktischen Modellierungsansatzen – wie ob-jektorientierten Sprachen und der UML – keine Ansatze zur nachrichtensynchronenModellierung von Systemen. Das hat letztlich damit zu tun, dass die praktisch ty-pischen Kommunikationsstrukturen bei verteilten Systemen (wie den Internet oderBussstrukturen) eher dem Konzept asynchroner Kommunikation entsprechen. ImZusammenhang mit der Idee des Transputers, eines flexibel kombinierbaren Hard-warebaussteins, entsteht die praktisch einsetzbare Sprache Occam, die wesentlichauf die Ideen von CSP abgestutzt ist. Allerdings hat sich der Transputer trotz viel-versprechender Konzepte nicht durchsetzen konnen.

6.6. Ubungsaufgaben

Ubungsaufgabe 6.1: Beschreiben Sie das Ergebnis der Zusammensetzung derAutomaten aus Abb. 6.2 durch ein Petri-Netz.

186 18. Marz 2014

7. Von der Zustands- zur Ablaufsicht

Wir haben bisher eine Reihe unterschiedlicher Sichten auf Systeme behandelt, aberden Zusammenhang zwischen den Sichten nur punktuell beschrieben. In den nachs-ten Kapiteln wird der Zusammenhang genauer dargestellt. Im folgenden Kapitelbehandeln wir den Ubergang von der Zustands- zur Ablaufsicht.

Zustande fassen die Informationen zusammen, die auf das Verhalten des SystemsEinfluss haben. Zustande konnen immer als Abstraktion von partiellen Ablaufenverstanden werden. In einem Zustand sammeln wir zumindest diejenigen Informa-tionen aus einem Teilablauf auf, die wir benotigen, um die Fortsetzung des Ablaufsbestimmen zu konnen.

7.1. Aktionsstrukturen und Zustandsbegriffe

Ablaufe bilden ein Modell des Verhaltens verteilter Systeme, indem die”Geschichte“

von Systemablaufen wiedergegeben wird. Eine komplementare Sicht auf Systemebekommen wir durch das Konzept des Systemzustands.

Durch Zustande lassen anschaulich dauerhafte, fur das zukunftige Verhalten rele-vante Wirkungen von Aktionen erfassen. Fur jedes (verteilte) System sind sehr unter-schiedliche Zustandsbegriffe denkbar. Jeder Zustandsbegriff induziert eine Aquiva-lenzrelation auf den endlichen Teilablaufen eines Systems. Zwei Teilablaufe sind zu-standsaquivalent, wenn sie zum gleichen Zustand fuhren (die gleiche Zustandsuber-gangsfunktion induzieren).

Ein Zustandsbegriff fur ein verteiltes System ist adaquat, wenn sich aus jedem AdaquaterZustandsbe-griff

Zustand die Menge der moglichen weiteren Ablaufe bestimmen lasst. Ein Zustands-konzept heißt voll abstrakt (im Sinne von nicht redundant), wenn unterschiedlichenZustanden auch unterschiedliche Mengen von moglichen weiteren Ablaufen zugeord-net werden (vgl. minimaler Automat in formalen Sprachen). In einem adaquaten,voll abstrakten System enthalten die Zustande keine Redundanz, sondern genau dieInformation, die benotigt wird um das Verhalten eines Systems in beliebige Umge-bungen eindeutig festzulegen.

Sei A eine Menge von Aktionen, und ein System durch eine Menge von unvoll-standigen und vollstandigen Ablaufen gegeben. Sei weiter eine Menge Σ und eineZustandsubergangsrelation

→ ⊆ Σ× ActStructfin(A)× Σ

18. Marz 2014 187

Kapitel 7. Von der Zustands- zur Ablaufsicht

gegeben. Wir schreiben

σ8p−→ σ′ fur (σ8,p, σ′) ∈ →

Diese Relation bedeutet, dass im Zustand σ8 der endliche Ablauf p moglich ist undvom Zustand σ8 zum Zustand σ′ fuhrt (genauer: fuhren kann).

Wir fordern fur Ablaufe p,p′,p′′ ∈ ActStructfin(A) folgende Eigenschaften fur dieZustandstransitionsfunktion:

(1) ZwischenzustandsaxiomZu jedem Prafix p′ v p existiert ein Zwischenzustand:

σ8p−→ σ′ ∧ p′ v p⇒ ∃ σ : σ8

p′−→ σ ∧ σ8 p′′−→ σ′

mit p′′ = p|dom(p)\dom(p′)

(2) Kompositionsaxiom (Verallgemeinerung der Transitivitat)

σ8p′−→ σ ∧ σ p′′−→ σ′ ⇒

∃ p : p′ v p ∧ p′′ = p|dom(p)\dom(p′) ∧ σ8p−→ σ′

Bei einer Beschrankung auf sequentielle Aktionsstrukturen ist die Zustandsuber-gangsrelation durch die Zustandsubergange fur den leeren Ablauf p∅(dom(p∅) = ∅)und atomare Ablaufe (|dom(p)| = 1) eindeutig bestimmt.

7.2. Temporale Logik zustandsorientierter Systeme

Zustandsmaschinen mit durch Aktionen markierten Ubergangen besitzen sequenti-elle Ablaufe der Form (es gilt σi ∈ Σ,ai ∈ Action):

σ0a1−→ σ1

a2−→ σ2a3−→ . . .

ai−→ σiai+1−→ . . .

Diese Ablaufe konnen, abhangig davon, ob die Berechnung der Zustandsubergangs-maschine terminert oder nicht, endlich oder unendlich sein. Beschranken wir uns derEinfachheit halber auf unendliche Ablaufe, so erhalten wir als Ablauf einen unendli-chen Strom von Paaren (σi, ai+1) bestehend aus dem Zustand σi und der im Zustandσi ausgefuhrten Aktion ai+1. Wieder konnen wir Methoden der temporalen Logikanwenden um Eigenschaften solcher Ablaufe mit logischen Formeln zu beschreiben.

Durch das Konzept der Bereitschaft von Aktionen in den betrachteten Zustandenlassen sich auch gebrauchliche Fairnessannahmen formulieren. Fur viele Systembe-schreibungen sind Fragen der Fairness von zentraler Bedeutung. Sie erlauben es,Eigenschaften, wie

”jede standig bereite Aktion wird irgendwann ausgefuhrt“, zu

beschreiben, ohne dafur eine konkrete Implementierung anzugeben.

188 18. Marz 2014

7.2. Temporale Logik zustandsorientierter Systeme

Ein unendlicher Ablauf eines Systems kann nun durch einen Strom s ∈ Stream(Σ,Action) von Paaren bestehend aus Zustand und der ausgehend vom Zustand aus-gefuhrten Aktion dargestellt werden. Wir schreiben dabei das Pradikat

exec(a)

falls in dem Paar (σ,b) aus Zustand und Aktion die Aktion in a mit der ausgefuhrtenAktion b ubereinstimmt.

Wieder arbeiten wir mit temporalen Formeln, die Pradikate fur Ablaufe darstellen.Der Ablauf s heißt stark fair, falls fur s folgende Aussage fur alle Aktionen a gilt: stark

(schwach)fairer Ablauf2[(2 enabled(a))⇒ ♦ exec(a)]

Der Ablauf s heißt schwach fair, falls folgende Aussage fur alle Aktionen a gilt:

2[(2 ♦ enabled(a))⇒ ♦ exec(a)]

Man beachte den subtilen Unterschied zwischen den beiden Formeln.

Achtung: Das Pradikat enabled(a) ist true fur ein Zustand σ, wenn a ∈enabled(σ), wobei enabled wie folgt definiert ist:

enabled(σ) = {a ∈ A : ∃σ′ ∈ Σ : σa−→ σ′}

Die spezifizierten Fairnesseigenschaften sind Lebendigkeitseigenschaften eines Ab-laufs, bzw. genauer einer Menge von Ablaufen.

Sicherheitseigenschaften lassen sich auf Zustandsstromen, wie bereits gesagt, durchpermanente Invarianten ausdrucken (in manchen Fallen muss zur Formulierung derEigenschaften der Zustandsraum um Hilfsvariable erweitert werden).

Fur Lebendigkeitseigenschaften konnen wir spezielle Pradikate verwenden. Wirschreiben fur Pradikate

P,Q : Σ→ B

die Formel

P leads to Q

Diese Formel ist fur eine Menge von Ablaufen (und damit fur ein System, das nursolche Ablaufe besitzt) erfullt, falls in jedem Ablauf gilt: Jeder Zustand im Strom,in dem das Pradikat P gilt, wird von einem Zustand gefolgt, in dem Q gilt. DieseFormel ist fur einen Zustandsstrom demnach gultig, falls das Pradikat

2[P⇒ ♦Q]

gilt. Mit anderen Worten, gerat das System in einem Ablauf in einen Zustand, indem das Pradikat P gilt, so erreicht es spater irgendwann einen Zustand, in demdas Pradikat Q gilt. Durch leads to lassen sich Lebendigkeitsaussagen besonderseingangig und verstandlich beschreiben.

18. Marz 2014 189


7.3. Aquivalenzbegriffe fur Zustandsmaschinen mit

markierten Ubergangen

Ein Zustandsubergangssystem mit markierten Zustandsubergangen generiert einer-seits eine Menge von (endlichen oder unendlichen) Ablaufen (ein Strom von Zustandenund Aktionen). Wir konnen auch einen Baum (mit moglicherweise unendlichen Pfa-den) mit einem Zustandsubergangssystem mit markierten Zustandsubergangen ver-binden, in dem alle Zustandsubergange dargestellt sind (vgl. die Baume fur CSP –Kapitel 6).

Die Modellierung verteilter, interaktiver Systeme setzt immer auch eine Abstrak-tion voraus: Viele aus der speziellen Sicht einer Systementwicklung unerheblicheDetails werden ignoriert und in der Modellbildung nicht berucksichtigt. Interessantist in diesem Zusammenhang die Frage, wann wir zwei Systeme in Bezug auf einebestimmte Modellbildung fur aquivalent ansehen. Bei einer gut gewahlten Begriffs-bildung sollten wir in der Lage sein, ein System durch ein aquivalentes zu ersetzen,ohne dass sich fur die Anwendung gravierende Unterschiede ergeben. das entsprichtdem Begriff der Kompatibilitat.

Modellieren wir Systeme durch Zustandsubergangsmaschinen, so bieten sich un-terschiedliche Aquivalenzbegriffe an.

Ein fundamentaler Aquivalenzbegriff fur Zustandsmaschinen ist die Aktionsspur-aquivalenz. Zwei Zustandsmaschinen heißen aktionsspuraquivalent, wenn ihre Men-Aktionsspur-

aquivalenz gen von Ablaufen, gegeben durch ihre Spuren von Aktionen, ubereinstimmen. Diesentspricht anschaulich der Gleichheit (wenn wir davon absehen, dass wir bei Ablaufenauch unendliche Strome zulassen) der durch die Automaten beschriebenen formalenSprachen. Die Spuraquivalenzrelation von den Zustandsmaschinen M1 und M2 istwie folgt bezeichnet:

M1 ∼Spur M2

Diese Begriffsbildung konnen wir einfach auch auf Zustandsstrome ubertragen. Wirsprechen deshalb auch allgemein von der Ablaufaquivalenz zweier Systeme.

Um fur Zustandstransitionen einen adaquaten Begriff der Aquivalenz auch in Be-zug auf die Bereitschaft, Aktionen auszufuhren, zu erhalten, fuhren wir den Begriffder Bisimulation ein.

Definition: BisimulationBisimulation

Eine Aquivalenzrelation∼ auf der Menge der Zustande heißt eine Bisimulation (nachR. Milner [MS92]), wenn folgende Formel gilt:

σ ∼ σ′ ⇔ (∀ a ∈ ActStructfin(A) : ∀ σ1 ∈ Σ :

(σa−→ σ1 ⇒ (∃ σ2 ∈ Σ : σ′

a−→ σ2 ∧ σ1 ∼ σ2))

∧ (σ′a−→ σ1 ⇒ (∃ σ2 ∈ Σ : σ

a−→ σ2 ∧ σ1 ∼ σ2)))

190 18. Marz 2014

7.3. Aquivalenzbegriffe fur Zustandsmaschinen mit markierten Ubergangen

Diese Definition sagt, dass die zwei Zustande σ und σ′ in einer Bisimulation-Relationgenau dann sind, wenn fur jede Aktion a folgendes gilt:

� jeder Zustand σ1, der wir von σ durch Aktion a erreichen konnen, ist in derBisimulation-Relation aquivalent zu einem Zustand σ2, den wir von σ′ durcheine mit a markierte Transition erreichen konnen;

� jeder Zustand σ1 der wir von σ′ durch Aktion a erreichen konnen, ist in derBisimulation-Relation aquivalent zu einem Zustand σ2, den wir von σ durcheine mit a markierte Transition erreichen konnen.

Durch eine Bisimulation werden hochstens solche Zustande als aquivalent angese-hen, die bzgl. der Zustandsubergange als

”beobachtbar gleich“ angesehen werden

konnen, das heißt, von denen die gleichen Zustandsubergangen zu den bisimulati-onsaquivalenten Zustanden moglich sind.

Der Unterschied zwischen Spur- und Bisimulationsaquivalenz wird bereits an demin Abb. 7.1 angegebenen einfachen Beispiel anschaulich sichtbar.

Beispiel 7.1: Zwei Systeme, die spur-, aber nicht bisimulationsaquivalent sind

Die Zustandsmaschinen M1 und M2 aus Abb. 7.1 sind spuraquivalent: M1 ∼Spur M2,weil ihre Mengen von Ablaufen ubereinstimmen: {{a,b}, {a, c}}. Diese Maschinensind aber nicht bisimulationsaquivalent.

M1: M2:

a

b

aa

c b c

Abb. 7.1.: Zwei Maschinen, die spur-, aber nicht bisimulationsaquivalent sind

Bei Bisimulationsaquivalenz σM11 ∼ σM2

1 musste namlich folgendes gelten:

∀ σ ∈ Σ : σM21

a−→ σ ⇒ ∃ σ′ ∈ Σ : σM11

a−→ σ′ ∧ σ ∼ σ′

Als σ brauchen wir hier nur σM22 nehmen, fur σ′ haben wir zwei Moglichkeiten

(σM12 und σM1

3 ). Fur mindestens fur einen von diesen Zustande sollte folgende Formelwahr sein, falls die Bisimulation gilt:

18. Marz 2014 191


(1) σM21

a−→ σM22 ⇒ σM1

1a−→ σM2

2 ∧ σM22 ∼ σM1

2

(2) σM21

a−→ σM22 ⇒ σM1

1a−→ σM1

3 ∧ σM22 ∼ σM1

3

Beide Aussagen, (1) und (2), sind falsch, weil weder σM22 ∼ σM1

2 noch σM22 ∼ σM1

3

gilt: Im Zustand σM22 konnen wir zwei Aktionen (entweder b oder c) ausfuhren, im

Zustand σM12 nur b und im Zustand σM1

3 nur c. Folglich sind M1 und M2 nicht bisi-mulationsaquivalent. 2

Wir konnen das Konzept der Bisimulation verwenden, um uber die Aquivalenz derZustande einer Maschine zu sprechen, oder um uber die Aquivalenz der Zustandeverschiedener Zustandsmaschinen zu sprechen.

Welche Aquivalenzrelation fur Zustande und Zustandsmaschinen geschickterwei-se gewahlt wird, hangt letztlich von der Frage ab, welche Kompositionsoperatorenbetrachtet werden, und welche Form der Kommunikation gewahlt wird. SynchroneKommunikation wird besser durch Bisimulationsrelationen behandelt, wohingegenfur asynchrone Kommunikation in der Regel die Spuraquivalenz ausreicht.

Man beachte, dass aus der Bisimulationsaquivalenz zweier Zustande die Spuraqui-valenz folgt, aber nicht umgekehrt.

Die meisten Systeme und die Kompositionsoperationen auf Systemen sind durchdie Spuraquivalenz angemessen zu formalisieren. So gilt fur die Kompositionsopera-tionen auf Zustandsmaschinen aus Abschnitt 2.7.1 die folgende Aussage:

∆2 ∼Spur ∆3 ⇒ ∆1‖∆2 ∼Spur ∆1‖∆3

Mit anderen Worten gilt folgende Aussage: Bezuglich der parallelen Kompositionasynchroner Systeme aus Abschnitt 2.7.1 ist die Spuraquivalenz eine Kongruenzre-lation. Dies gilt nicht fur parallele Komposition synchroner Systeme.

7.4. Der Zusammenhang zwischen Bisimulation und

Verweigerungsaquivalenz

Fur Systeme mit synchronem Austausch von Nachrichten nach dem Rendezvous oderHandschlagskonzept (engl. handshaking) ist die Spuraquivalenz keine Kongruenzre-lation, wenn wir in der parallelen Komposition das Zusammenfuhren von Sendenund Empfangsaktion nach der Bereitschaft durchfuhren und ferner die Moglichkei-ten haben, in bewachten Anweisungen parallel mehrere Kommunikationsaktionenanzubieten.

Im Folgenden zeigen wir, dass fur solche Systeme die Bisimulation eine Kongru-enzrelation ist. Genau genommen fuhren wir zunachst eine neue Aquivalenzrelati-on ein, die so genannte Bereitschaftsaquivalenz. Dann zeigen wir, dass die Bereit-schaftsaquivalenz die Bisimulationsaquivalenz impliziert und zeigen ferner, dass die

192 18. Marz 2014

7.4. Der Zusammenhang zwischen Bisimulation und Verweigerungsaquivalenz

Bereitschaftsaquivalenz selbst keine Bisimulation ist. Dies zeigt, dass bisimulati-onsaquivalente Agenten auch bereitschaftsaquivalent sind.

Das Konzept der Bisimulation geht zuruck auf David Park. Es wurde spatervon Robin Milner verwendet, um eine Kongruenzrelation fur eine zu unserer Spra-che ahnliche Agentensprache, namens CCS (Calculus for Communicating Systems, CCS

[Mil89]), einzufuhren. Ein anderer Ansatz wurde von Tony Hoare gewahlt, der furdie von ihm entworfenen Agentensprache CSP (Communicating Sequential Proces-ses) nach langerem Suchen schließlich ein denotationelles Modell (vgl. [Hoa85a] und CSP

[Sto77]) auf Basis der Bereitschaftsmengen angeben konnte. Dies erlaubt auch eineBereitschaftsaquivalenz auf Zustandsmaschinen mit aktionsmarkierten Ubergangenzu fuhren. Im Folgenden werden wir auch diese Aquivalenzrelation definieren undden Zusammenhang zur Bisimulation herstellen.

Wieder betrachten wir Zustandsubergangssysteme mit einer Zustandsmenge undeiner Aktionsmenge A und Zustandsubergangen fur Zustande und Aktionen in derfolgenden Form:

σ1a−→ σ2

Dieser Ausdruck steht fur die logische Aussage, dass im Zustand σ1 die Aktion a aus-gefuhrt werden kann und diese in den Zustand σ2 fuhren kann. Um unsere Darlegungeinfach zu halten, betrachten wir keine so genannten

”stillen“ Schritte (engl.

”silent

move“), auch ε-Ubergange (oder bei Milner τ -Ubergange) genannt, sondern be-schranken uns ausschließlich auf Systeme mit nicht stillen Aktionsubergangen. Aufdiese Weise vermeiden wir einige vertrackte Probleme mit divergierenden Berechnun-gen, bei denen eine unendliche Folge von ε-Schritten auftreten. Unsere Diskussionwird dadurch erheblich vereinfacht, das Ergebnis ist im Wesentlichen aber auf denkomplizierteren Fall ubertragbar.

Wann eine Relation eine Bisimulation genannt wird, haben wir bereits im voraus-gehenden Abschnitt definiert. Wir wiederholen die Definition kurz. Die Relation ∼auf der Menge der Zustande wird Bisimulation genannt, falls Relationen genauerPraordnungen auf den Zustanden σ1 und σ2 existieren, so dass gilt:

σ1 ∼ σ2 ≡ σ1 ≤ σ2 ∧ σ2 ≤ σ1

Dabei ist ≤ eine Relation, genauer eine Praordnung auf Zustanden, die folgendeEigenschaft erfullt:

σ1 ≤ σ2 ≡ (σ1 = σ2

∧ ∀ a ∈ A, σ3 ∈ Σ : σ1a−→ σ3 ⇒ ∃ σ4 ∈ Σ : σ2

a−→ σ4 ∧ σ3 ≤ σ4)

Wir nennen die Relation ≤ auch eine Bisimulationspraordnung oder kurz auch eineSimulation.

Wenn wir Abb. 7.1 betrachten, erkennen wir unschwer, dass σM11 ≤ σM2

1 gilt, aberσM2

1 ≤ σM11 nicht gilt.

18. Marz 2014 193


Um die Idee einer Bereitschaftsmenge zu erlautern, fuhren wir folgende Definitionein: Fur jeden Zustand definieren wir die Menge der bereiten Aktionen als Teilmengeder Aktionsmenge A wie folgt:

enabled(σ) = {a ∈ A : ∃ σ′ ∈ Σ : σa−→ σ′}

Die Bereitschaftsaquivalenz, wie sie in der genannten Sprache CSP (fur ausfuhrliche-re Beschreibung vgl. Abschnitt 8) eingefuhrt worden ist, wird durch folgende Formeldefiniert. Dabei seien σ1 und σ2 Zustande.

σ1 ≈ σ2 ≡ σ1 v σ2 ∧ σ2 v σ1

Wobei v eine Relation auf Zustanden ist, die wie folgt definiert sei:

σ1 v σ2 ≡ ∀ t ∈ A∗ : Rt(σ1) ∠ Rt(σ2)

Rt(σ) bezeichnet die Menge der Bereitschaftsmengen fur alle Zustande, die vomAusgangszustand durch die Spur erreichbar sind.

Rt(σ0) = {enabled(σ) : σ0t−→ σ}

Die Relation ∠ auf der Menge von Mengen von Aktionen, das heißt auf der Potenz-menge uber der Menge A von Aktionen, wird durch folgende Formel festgelegt:

S1 ∠ S2 ≡ (S1 = ∅)∨ (S2 6= ∅ ∧ ∀ M ⊆ A : (∃ M2 ∈ S2 : M2 ∩M = ∅)⇒

(∃ M1 ∈ S1 : M1 ∩M = ∅))

Die Formel druckt aus, dass die Menge S2 (betrachtet als Menge von Bereitschafts-mengen) ein Angebot M ⊆ A immer ablehnen kann, wenn das auch die Teilmenge S1

kann.

Beispiel 7.2: Zwei Prozesse, die bereitschafts-, aber nicht bisimulationsaqui-valent sindDie beiden Prozesse werden in der Abb. 7.2 dargestellt. Fur die angegebenen Zustandegilt die Bisimulationspraordnung σ1 ≤ σ2, aber die Bisimulationspraordnung σ2 ≤ σ1

gilt nicht.

σ1 ≤ σ2 :

(1) σ1a−→ σ3 und ∃ σ5 : σ2

a−→ σ5 ∧ σ3 ≤ σ5, σ3 ≤ σ5 gilt, weil in den beidenZustanden konnen wir nur die gleiche Aktion b ausfuhren;

(2) σ1a−→ σ4 und ∃ σ7 : σ2

a−→ σ7 ∧ σ4 ≤ σ7, σ4 ≤ σ7 gilt, weil in den beidenZustanden konnen wir nur die gleiche Aktion c ausfuhren.

194 18. Marz 2014

7.4. Der Zusammenhang zwischen Bisimulation und Verweigerungsaquivalenz

a

b

aa

c b c

aa

b c

Abb. 7.2.: Zwei Maschinen, die spur-, aber nicht bisimulationsaquivalent sind

σ2 ≤ σ1 gilt nicht, weil folgendes nicht gilt:

∃σ : σ1a−→ σ ∧ σ6 ≤ σ

Hier ist zu beachten, dass fur den Fall σ2a−→ σ6, weder σ6 ≤ σ3 noch σ6 ≤ σ4 gilt.

Jedoch sind die beiden in Abbildung 7.2 dargestellten Prozesse verweigerungsaqui-valent. Wir zeigen das, indem wir folgende Formel beweisen:

σ2 v σ1 ∧ σ1 v σ2

Dazu definieren wir die beiden Bereitschaftsmengen:

S1 = {enabled(σ) : σ1a−→ σ} = {{b}, {c}}

S2 = {enabled(σ) : σ2a−→ σ} = {{b}, {c}, {b, c}}

Trivialerweise gilt:

S2 ∠ S1

als auch

S1 ∠ S2

da wir, wenn immer eine Menge M disjunkt mit einer Menge M1 aus S1 ist, eineMenge M2 und S2 finden konnen, die disjunkt zu M ist und umgekehrt. 2

Tatsachlich gilt: Falls eine Menge S von Bereitschaftsmengen eine Menge enthalt, diedie Vereinigung von zwei der Elementen in S ist, dann andert es nichts an der Fahig-keit der Bereitschaftsmenge S, bestimmte Angebote zuruckzuweisen. Dies wird inder von Tony Hoare entwickelten Theorie dadurch berucksichtigt, dass er fur Bereit-schaftsmenge grundsatzlich fordert, dass jede Vereinigung von Bereitschaftsmengenwieder selbst Bereitschaftsmenge ist.

18. Marz 2014 195


Unser obiges kleines Beispiel zeigt bereits, dass die Bereitschaftsaquivalenz keineBisimulation ist. Nun zeigen wir, dass jede Bisimulationsaquivalenz auch die Bereit-schaftsaquivalenz impliziert. Es ist das Ergebnis des folgenden Satzes.

Satz: Bisimulationsaquivalenz impliziert BereitschaftsaquivalenzBeweis: Wir beweisen fur beliebige Zustande σ1 und σ2 die Aussage:

σ1 ≤ σ2 ⇒ σ1 v σ2

Dazu beweisen wir fur alle Spuren Formel:

σ1 ≤ σ2 ⇒ {enabled(σ) : σ1t−→ σ} ∠ enabled(σ) : σ2

t−→ σ}}

Es gilt:

σ1 ≤ σ2 ⇒ {enabled(σ1)} ∠ {enabled(σ2)}

diese Aussage ist trivial, denn durch die Definition von ≤ erhalten wir die Relation:

enabled(σ1) ⊆ enabled(σ2)

aus der zwingend die Aussage folgt. Ein einfacher Beweis nach Induktion uber dieLange der Spur t zeigt:

σ1 ≤ σ2 ∧ σ1t

=⇒ σ3 ⇒ ∃ σ4 : σ2t

=⇒ σ4 ∧ σ3 ≤ σ4

Wir erhalten aufgrund der Aussage die Schlussfolgerung:

enabled(σ3) ⊆ enabled(σ4)

Dies zeigt, dass die Bereitschaftsaquivalenz der Zustande σ1 und σ2 gilt, falls wirnur annehmen, dass diese beiden bisimular sind. 2

Der obige Satz zeigt insbesondere, dass die Verweigerungsaquivalenz eine abstraktereAquivalenzrelation ist als die Bisimulation. Es gibt Zustande, die verweigerungsaqui-valent, aber nicht bisimular sind. Allerdings ist die Bisimulation auch trotzdemnutzlich, da es gelegentlich interessant ist, die Bisimularitat von zwei Zustandenzu beweisen, da aus der Bisimularitat auch bereits die Verweigerungsaquivalenz unddie Spuraquivalenz folgen.

7.5. Historische Bemerkungen zum Zusammenhang zwischen

Zustands- und Ablaufsicht

Es ist symptomatisch, dass das Gebiet der verteilten Systeme durch eine Vielzahl vonEinzelansatzen gepragt ist, die oft nicht genugend zueinander in Beziehung gesetzt

196 18. Marz 2014

7.5. Historische Bemerkungen zum Zusammenhang zwischen Zustands- undAblaufsicht

werden. Wir finden eine ganze Reihe individueller Vorschlagen fur die Modellierungvernetzter Systeme, die ganz bestimmten Sichten auf ein System in den Mittelpunktstellen und diese in allen Einzelheiten ausnutzen, um einen Entwicklungsansatz furvernetzte Systeme zu bekommen. Typischerweise konnen diese Ansatze unterteiltwerden in starker zustandsorientierte oder starker ablauforientierte Vorschlage. Zuwenige Arbeiten existieren, die sich bemuhen, den Zusammenhang zwischen denunterschiedlichen Sichten herzustellen.

So wurde beispielsweise in den 80er Jahren ein umfassender theoretischer Ansatzmit einer komplexen Theorie unter dem Stichwort

”Event Structures“ (vgl. [Win89])

entwickelt, in denen ausfuhrlich uber die Ablaufsicht von Systemen theoretisch gear-beitet wurde. Unter dem Stichwort der Prozessalgebren (vgl. [BS01a]) wurden bei-spielsweise operationelle Semantiken (wie im Kapitel uber synchrone Systeme furCSP gezeigt) entwickelt, die zunachst auf den ersten Blick starker ablauforientiertaussehen.

Fur alle diese Ansatze lasst sich aber ein enger Bezug zur Zustandssicht herstel-len, wenn man die auftretenden Terme zur Beschreibung von Systemen als Zustandedeutet. Starker pragmatische Ansatze betonen stark die Zustandssicht und nutzendie Moglichkeiten aus, die sich aus den Erweiterungen der Zusicherungslogik aufverteilte Systeme ergibt. Im vorangegangenen Kapitel wurde versucht, den engenZusammenhang und die Dualitat zwischen den Zustands- und der Ablaufsicht her-auszuarbeiten.

18. Marz 2014 197


198 18. Marz 2014

8. Verfeinerung von Systemen

Im Software Engineering und im Systems Engineering entwickeln wir typischerwei-se ein System schrittweise. Dabei beschreiben wir Systeme zunachst unvollstandig,eher abstrakt und stark vereinfacht und dann immer detaillierter in einer Reiheunterschiedlicher geeignet gewahlter Abstraktionsebenen. Wir sprechen bei dieserVorgehensweise von schrittweiser Verfeinerung.

Wir definieren in diesem Kapitel Verfeinerungskonzepte, die es einerseits erlauben,Spezifikationen innerhalb einer Abstraktionsebene und andererseits auch Spezifika-tionen auf unterschiedlichen Abstraktionsebenen zueinander in Beziehung setzen.Grundsatzlich unterscheiden wir zwei Arten von Verfeinerung

� Eigenschaftsverfeinerung : In einer Systementwicklung legen wir zuerst die Eigenschafts-verfeinerungsyntaktische Schnittstelle eines Systems fest und spezifizieren dann schrittweise

mehr und mehr Eigenschaften. Das Hinzufugen weiterer Eigenschaften zu einerSpezifikation nennen wir eine Eigenschaftsverfeinerung.

� Reprasentationsverfeinerung : In der Regel werden Systeme im Laufe ihrer Reprasentations-verfeinerungEntwicklung auf unterschiedlichen Abstraktionsebenen beschrieben. Die Ab-

straktionsebenen konnen unterschiedliche Datenreprasentation verwenden, un-terschiedliche Zustande, Kanalnamen, -sorten und -mengen, und damit eineunterschiedliche Granularitat des Nachrichtenaustauschs.

Die formale Definition der Eigenschaftsverfeinerung ist einfach, die der Reprasenta-tionsverfeinerung etwas komplizierter. Wir arbeiten in beiden Fallen zunachst nurmit dem Schnittstellenmodell gegeben durch stromverarbeitende Funktionen.

8.1. Eigenschaftsverfeinerung

Wie in den vorangegangenen Kapiteln demonstriert, konnen Systeme durch die An-gabe logischer Eigenschaften beschrieben werden. Zur Spezifikation des Schnittstel-lenverhaltens wird die syntaktische Schnittstelle angegeben und eine Schnittstellen-zusicherung. Dadurch wird ein Verhalten spezifiziert, dass eine Verhaltensfunktion

f : ~I → ℘(~O)

beschreibt.Eine Komponente mit dem Verhalten

f : ~I → ℘(~O)

18. Marz 2014 199

Kapitel 8. Verfeinerung von Systemen

wird durch eine Komponente mit dem Verhalten:

f : ~I → ℘(~O)

verfeinert, falls fur alle Eingaben x ∈~I:

f(x) ⊆ f(x)

gilt.

Wir geben zur Erlauterung zunachst ein einfaches Beispiel fur eine Komponen-tenspezifikation. Wir beschreiben einen einfachen unbeschrankten Datenspeicher.

Beispiel 8.1: Verfeinerung am Beispiel DatenspeicherEin Datenspeicher speichert Daten und gibt diese auf ein Anforderungssignal zuruck.Er besitzt einen Eingabekanal x der Sorte

Data | {req}

und einen Ausgabekanal y der Sorte

Data

Diese Nachricht req stellt das Anforderungssignal dar. Eine einfache Forderung furdie Speicherfunktion f besteht in der Festlegung (fur alle d ∈ Data):

y ∈ f(x) ∧ d ∈ y⇒ d ∈ x (1)

Dies besagt, dass nur Data ausgegeben werden, die auch empfangen wurden. Dabeisollten hochstens soviele Daten ausgegeben werden, wie eingegeben und angefordertwerden ( c© bezeichnet hier eine Filterfunktion):

#y = min(#{req} c©x, #Data c©x) (2)

Ferner sollten fur jede Datenelement hochstens soviele Kopien ausgegeben werden,wie eingegeben und angefordert werden:

#{d} c©y ≤ #{d} c©x (3)

Wir erhalten durch diese drei Schnittstellenzusicherungen drei Funktionen f1, f2, f3,wobei wir annehmen, dass f1 die Zusicherung (1) erfullt, f2 zusatzlich die Zusiche-rung (2) und f3 alle drei Zusicherungen erfullt. Dies ergibt bereits drei Beispiele furVerfeinerungsschritte. Weitere Verfeinerungen sind denkbar (wie die Festlegung, inwelcher Reihenfolge die Daten ausgegeben werden). 2

200 18. Marz 2014

8.2. Teilfunktionalitat

Das Beispiel zeigt ein einfaches Prinzip. Erfullen die Verhalten

f, f : ~I → ℘(~O)

die Schnittstellenzusicherungen:

y ∈ f(x) ⇔ R(x, y)

y ∈ f(x) ⇔ R(x, y)

dann ist f genau dann Verfeinerung des Schnittstellenverhaltens f, falls fur alle x ∈~I,y ∈ ~O

R(x, y)⇒ R(x, y)

Die Verfeinerungsrelation entspricht bei Schnittstellenzusicherungen der Implikati-on.

Das Verhalten f ist eine Verfeinerung des Verhaltens f falls fur jede Eingabe x je-de Ausgabe von eine Ausgabe von f ist. Somit erfullen alle Ausgaben von f alleEigenschaften der Ausgaben von f, aber in der Regel noch mehr Eigenschaften.

8.2. Teilfunktionalitat

Bei der Eigenschaftsverfeinerung haben wir zwei Verhalten f, f betrachtet, die aufden gleichen Mengen I bzw. O von Eingabe- und Ausgabekanalen arbeiten. Nunbetrachten wir Eingabekanale I, I′ und Ausgabekanale O, O′ mit

I ⊆ I′ ∧ O ⊆ O′

und Verhalten

f :~I→ ℘(~O)

f′ : ~I′ → ~O.

Das System f′ hat also mehr Kanale als das System f. Wir nennen f eine Teilfunktion Teilfunktion

von f′, wenn folgende Formel fur alle x ∈ ~I′ gilt:

f(x | I) = f′(x) | O

dabei bezeichnen wir mit x | I die Restriktion der Belegung x der Kanale aus Idurch Strome auf die Kanale in I.

Zusatzlich konnen wir auch noch in den Kanalen von I und O bestimmte Nach-richten ausblenden, die in I′ und O′ vorhanden sind.

18. Marz 2014 201


8.3. Reprasentations- und Abstraktionsverfeinerung

Durch eine Eigenschaftsverfeinerung bleibt die syntaktische Schnittstelle einer Kom-ponente unverandert. Eine Reprasentationsverfeinerung (oder Schnittstellenverfei-nerung) erlaubt es uns, auch die syntaktische Schnittstelle einer Komponente zuandern. Wir betrachten die beiden Verhaltensbeschreibungen:

f : (I→ Mω)→ ℘(O→ Mω),

f : (I→ Mω)→ ℘(O→ Mω).

Um diese Verhaltensbeschreibungen zueinander in Beziehung setzen zu konnen, ver-wenden wir Ubersetzungsfunktionen. Wir sprechen von einer Interaktionsverfeine-rung. Seien Z und Z Mengen von Kanalnamen. Ein Paar von AbbildungenInteraktions-

verfeinerung

A : (Z→ Mω)→ ℘(Z→ Mω)

R : (Z→ Mω)→ ℘(Z→ Mω)

heißt Interaktionsverfeinerung, falls gilt

R ◦ A = Id

Hier bezeichnet”◦“ die Funktions- bzw. Relationenkomposition

(R ◦ A)(x) = {z ∈ A(y) : y ∈ R(x)}

und Id bezeichnet die Identitat

Id(x) = {x}.

Zur Beschreibung der Schnittstellenverfeinerung benotigen wir zwei Interaktionsver-feinerungen, eine fur die Eingabekanale und eine zweite fur die Ausgabekanale:

AI : (I→ Mω)→ ℘(I→ Mω), RI : (I→ Mω)→ ℘(I→ Mω),

AO : (O→ Mω)→ ℘(O→ Mω), RO : (O→ Mω)→ ℘(O→ Mω),

so dass gilt

RI ◦ f ◦ AO ⊆ f

Durch dieses Konzept wird festgelegt, wie gewisse Ein/Ausgabepaare auf der kon-kreten Ebene mit Ein/Ausgabepaaren auf der abstrakten Ebene in Beziehunggesetztwerden konnen.

Man beachte, dass die Eigenschaftsverfeinerung ein Spezialfall der Schnittstellen-verfeinerung ist. Wir brauchen nur fur alle auftretenden Funktionen AI,AO, RI, RO

die Identitat wahlen.

202 18. Marz 2014


Beispiel 8.2: Parallele und Serielle SubtraktionWir ubersetzen ein Paar von Zahlenstromen in einem Bitstrom mit Trennzeichen

”

√“:

rep(n & a,m & b) = bitseq(n) 〈√〉 bitseq(m) 〈√〉 rep(a,b)

rep(〈〉,b) = rep(d, 〈〉) = 〈〉

wobei bitseq(n) die Binarreprasentation der Zahl n durch eine Sequenz von Bits dar-stellt.

2

Interaktionsverfeinerung ist der Verfeinerungsbegriff fur die Modellierung von Ent-wicklungsschritten zwischen unterschiedlichen Abstraktionsebenen. Durch Interak-tionsverfeinerungen konnen wir bei einer Komponente

� die Sorte, Zahl und Namen ihrer Eingabe- und Ausgabekanale,

� die Granularitat der auf den Kanalen ubermittelten Nachrichten

verandern. Wir setzen die Komponenten, genauer ihr Schnittstellenverhalten, uberein Paar von Abstraktions- und Reprasentationsabbildungen zueinander in Bezie-hung.

Eine Interaktionsverfeinerung wird durch zwei Funktionen

A : ~C′ → ℘(~C) R : ~C→ ℘(~C′)

beschrieben, die die abstrakte und die konkrete Ebene eines Entwicklungsschrittsverknupfen, der, wie in Abb. 8.1 gezeigt wird, von einer Abstraktionsebene zurnachsten fuhrt. Ist eine abstrakte Historie x ∈ ~C gegeben, so bezeichnet jedes y ∈ R.xeine konkrete Historie, die die Historie x reprasentiert. Berechnet man eine Reprasen-tation fur eine gegebene abstrakte Historie und dann deren Abstraktion, erhalt manwieder die ursprungliche abstrakte Historie. Bei sequentieller Komposition wird diesdurch die Bedingung Reprasentations-

verfeinerungs-paarR ◦ A = Id

ausgedruckt. Id bezeichne die Identitatsrelation. A nennen wir die Abstraktions- undR die Reprasentationsfunktion. R und A nennen wir ein Reprasentationsverfeine-rungspaar.Durch Interaktionsverfeinerung konnen wir Komponenten verfeinern, wenn es jeweilspassende Verfeinerungspaare fur die Eingabe- und Ausgabekanale gibt.

Das Konzept einer Interaktionsverfeinerung wird in Abb. 8.2 fur die so genannteU−1-Simulation dargestellt. Man beachte, dass die Komponenten (Stromrelationen)AI und AO nicht mehr definitorisch im Sinn von Spezifikationen aufzufassen sind,sondern methodologisch, weil sie zwei Abstraktionsebenen verbinden. Nichtsdesto-weniger beschreiben wir sie mit den bislang eingefuhrten Spezifikationstechniken.

Sind die Verfeinerungspaare

18. Marz 2014 203


R A

…

…

…

…

Abstrakte Ebene

Konkrete Ebene

Abb. 8.1.: Verfeinerung der Kommunikations-Historie

AI

…

…

…

…

Abstrakte Ebene

Konkrete Ebene

RO

F

FI1

O2

O1

I2

Abb. 8.2.: Interaktionsverfeinerung (U−1-Simulation)

AI :~I2 → ℘(~I1) RI :~I1 → ℘(~I2)

AO : ~O2 → ℘(~O1) RO : ~O1 → ℘(~O2)

fur die Eingabe- und Ausgabekanale gegeben, konnen wir abstrakte und konkreteKanale fur die Eingabe und fur die Ausgabe verknupfen. Wir bezeichnen das E/A-Verhalten

F : ~I2 → ℘( ~O2)

als Interaktionsverfeinerung des E/A-Verhaltens

F :~I1 → ℘(~O1)

wenn der folgende Satz gilt:

F ⊆ AI ◦ F ◦ RO U−1 − Simulation

204 18. Marz 2014


Diese Formel besagt im Wesentlichen, dass F eine Eigenschaftsverfeinerung der Kom-ponente AI◦F◦RO ist. Damit lasst sich fur jede

”konkrete“ Eingabehistorie x ∈~I2 und

jede konkrete Ausgabe y ∈ ~O2 auch dadurch gewinnen, dass wir x in eine abstrakteEingabe-Historie x ∈ AI(x), ubersetzen, sodass wir eine abstrakte Ausgabehistoriey ∈ F(x) wahlen konnen und y ∈ RO gilt.

Es gibt noch drei weitere Spielarten von Interaktionsverfeinerung, die wir erhal-ten, indem wir die Aufwartsfunktion AI in Abb. 8.2 durch die Abwartsfunktion RI

ersetzen oder die Aufwartsfunktion AO durch die Abwartsfunktion RO oder beides.Wir erhalten jeweils die folgenden Charakterisierungen

RI ◦ F ⊆ F ◦ RO AbwartssimulationF ◦ AO ⊆ AI ◦ F AufwartssimulationRI ◦ F ◦ AO ⊆ F U-Simulation

Dies sind allesamt nutzliche Relationen um eine Beziehung zwischen Abstraktions-ebenen auszudrucken. Welche dieser Verfeinerungen in einem Entwicklungsschritt zuverwenden ist, hangt von den Umstanden ab. U−1-Simulation ist der restriktivste,

”starkste“ Begriff, der die anderen drei impliziert. Diese Behauptung lasst sich leicht

beweisen: Aus

F ⊆ AI ◦ F ◦ RO

leiten wir durch Multiplikation mit RI von links die Formel

RI ◦ F ⊆ RI ◦ AI ◦ F ◦ RO

ab und durch RI ◦ AI = Id erhalten wir die Aussage

RI ◦ F ⊆ F ◦ RO

Dies liefert die Charakterisierung der Abwartssimulation. Mit ahnlichen Argumentenbeweisen wir, dass F auch eine Aufwartssimulation und eine U-Simulation ist.

Eingehender wird dies im folgenden Abschnitt behandelt; weitere Einzelheitensind in [Bro93] zu finden.

Beispiel 8.3: Zeitfreie Identitat fur Nachrichten des Typs T3Hier werden wir die FOCUS-Notation (vgl. Kapitel B) fur die Spezifikation verwen-den. Fur die zeitfreie Identitat fur Nachrichten des Typs T3 lautet eine Komponen-tenspezifikation wie folgt:User Guide for the FOCUS representation in LATEX 11

TII3 timed

in z ′ : T3

out z : T3

z = z ′

18. Marz 2014 205


Wir erhalten

MRG ◦ TII3 ◦ FRK ⊆ TII

als einfaches Beispiel fur eine Interaktionsverfeinerung durch U-Simulation. Der Be-weis ist wiederum leicht zu fuhren.

Abb. 8.3 zeigt eine grafische Darstellung dieser Verfeinerungsrelation. 2

Das Konzept einer Interaktionsverfeinerung ist auch in anderen Ansatzen wie bei-spielsweise in TLA (Temporal Logic of Actions, vgl. [Lam94]) zu finden. Es wirdTLA

haufig in der praktischen Systementwicklung angewandt, obwohl es dort nur seltenformal ausgefuhrt wird. Beispiele dafur sind die Kommunikationsprotokolle in denISO/OSI-Hierarchien (vgl. [HB05]).

Achtung: Interaktionsverfeinerung ermoglicht eine Formalisierung der Bezie-hung zwischen verschiedenen Abstraktionsebenen in der Systementwicklung.

MRG FRK

TII

TII3

x

y

z

xx

x

y

y y

z z

z

Abb. 8.3.: Grafische Darstellung einer Interaktionsverfeinerung

Somit kann sie dazu dienen, die Schichten von Protokollhierarchien, die Verande-rung von Datenreprasentationen fur die Nachrichten oder die Zustande oder dieEinfuhrung von Zeit in Systementwicklungen zu verknupfen.

8.4. Modularitat und Kompatibilitat

Wir nennen eine Verfeinerungsrelation modular, wenn fur ein System die Verfei-nerung einer Komponente die Verfeinerung des Systems, indem die Komponenteangesiedelt ist, impliziert.

206 18. Marz 2014

8.5. Reprasentationsverfeinerung fur Zustandssysteme

Formal ausgedruckt, wird fur die Modularitat der Verfeinerung gefordert

f1 f′1 ∧ f2 f′2 ⇒ f1 ⊗ f2 f′1 ⊗ f′2

Dabei bezeichnet die Verfeinerungsrelation und ⊗ den Kompositionsoperator,durch den Systemarchitekturen gebildet werden.

Satz: Eigenschafts- und Reprasentationsverfeinerung sind modular.Beweis: Siehe [Bro93]. 2

Ein dem Begriff der Verfeinerung verwandter Begriff ist der Begriff der Kompatibi-litat. Den Begriff der Kompatibilitat gibt es in zwei Auspragungen:

� Ersetzungskompatibilitat : Eine Komponente A heißt ersetzungskompatibel zurKomponente B, wenn A in beliebigen Systemen fur B eingesetzt werden kann,ohne dass sich das Schnittstellenverhalten des Systems andert.

� Zusammensetzungskompatibilitat : Ein System A heißt zu einem System Bkompatibel fur eine Zusammensetzung, falls A mit B zu A ⊗ B komponiertwerden kann und ein

”sinnvolles“ Verhalten ergibt.

Wir betrachten primar das Konzept der Ersetzungskompatibilitat. Dazu definierenwir die Idee des Systemkontextes

K[f] = f⊗ g

fur gegebenes g. f′ ist ersetzungskompatibel fur f, falls

K[f] = K[f′]

oder (mit geeigneter Verfeinerungsrelation )

K[f] K[f′]

Es ergibt sich sofort, dass modulare Verfeinerung mit Erganzungskompatibilitatubereinstimmt.


In diesem Abschnitt behandeln wir die Verfeinerung von Zustandsraumen in Zu-standsubergangssystemen. Wir illustrieren, dass die Idee der Verfeinerung auf dieZustandssicht ubertragbar ist. Wir betrachten nur den einfachsten Fall, namlichunmarkierte nichtdeterministische Zustandsubergangssysteme.

Wie wir gezeigt haben, sind Sicherheitseigenschaften nichts anderes als Syste-minvarianten. Wie gemeinhin bekannt ist, hat jedes Zustandsubergangssystem einestarkste Invariante, die die Menge seiner erreichbaren Zustande kennzeichnet, und

18. Marz 2014 207


im Allgemeinen noch viele weitere, schwachere Invarianten. Im Folgenden unter-suchen wir die Beziehung zwischen verschiedenen Zustandsubergangssystemen undihren Invarianten.

Zustandssichten spiegeln die individuelle Granularitat der Zustandsubergangs-schritte einer Komponente wider. Zum Beispiel konnen wir mit einer Zustandsuber-gangsmaschine, die auf eine Eingabenachricht auf ihrem Eingabekanal c mit zweiAusgabenachrichten auf ihrem Ausgabekanal e antwortet, die Invariante beweisen,dass #e bei jede Eingabe geradzahlig ist. Wenn wir den Zustandsubergang mit zweiTransitionen implementieren, wovon die erste die Eingabe akzeptiert und eine Aus-gabenachicht sendet und die zweite dann keine Eingabe verlangt und eine zweiteNachricht sendet, gilt die genannte Invariante naturlich nicht mehr.

Lamport arbeitet in diesem Zusammenhang mit dem Konzept des”stuttering“

(vgl. [AL91]). Dies heißt, dass eine Zustandsmaschine in jeder Berechnung beliebigaber nur endlich viele

”leere“ Schritte machen darf, die den Zustand unverandert

lassen.

Generell hangt die Validitat einer Zustandsinvariante essentiell von der Granula-ritat (Atomizitat) der Zustandsubergange ab. Wohlbekannt ist dies aus der Lehreuber die zustandsbasierten parallelen Systemen, wenn es um die Atomizitat vonAnweisungen geht. Daher konnen wir die Invariante zu einer reinen Sicherheitsei-genschaft abschwachen.

Um die Sicherheitseigenschaften von Systemen mit Hilfe von Zustandszusicherun-gen zu analysieren, sind zwei Aufgaben zu bewaltigen:

(a) Invarianten beweisen,(b) Gegenbeispiele fur Invarianten finden.

Aufgabe (a) wird durch Verifikation gelost, (b) durch Testen. Sind die Zustandsraumeklein genug, ist beides mittels Model Checking moglich (vgl. [BVW94] und [CGP99]).Beim Model Checking wird in effizienter Weise der Raum der erreichbaren Zustandeabgesucht. Dadurch wird (a) bewaltigen, falls die Aussage fur alle erreichbare Zustandegilt, oder, falls eine Invariante nicht verifiziert werden kann, werden Gegenbeispiele(im Sinne der Folge von Zustandsubergangen, die auf einen Zustand fuhren, in demdie Zusicherung verletzt ist) geliefert. Leider funktioniert Model Checking praktischnur in einer eingeschrankten Zahl von Fallen bei hinreichend kleinen, endlichen Zu-standsmaschinen.

Man beachte, dass es unsere Methode erlaubt, Invarianten fur abstraktere Zu-standssichten durch Invarianten fur konkretere Zustandssichten zu beweisen. Umdies zu erlautern, fuhren wir Abstraktionsfunktionen zwischen Zustandsraumen ein.

Sind ein”abstrakter“ Zustandsraum Σ, ein

”konkreter“ Zustandsraum Σ′, und

zwei Zustandsubergangsfunktionen

∆ : Σ→ ℘(Σ)

∆′ : Σ′ → ℘(Σ′)

208 18. Marz 2014


mit der Menge von Anfangszustanden Σ0 ⊆ Σ und Σ′0 ⊆ Σ′, gegeben, so be-zeichnen wir das System (∆, Σ0) als Abstraktion des Systems (∆′, Σ′0), wenn eineAbstraktionsfunktion

α : Σ′ → Σ

fur die Zustandsraume Σ′ und Σ existiert, sodass fur alle Zustande σ, σ1, σ2 ∈ Σ′ gilt

σ ∈ Σ′0 ⇒ α(σ) ∈ Σ0

σ′ ∈ ∆′(σ)⇒ α(σ′) ∈ ∆(α(σ))

Die zweite Formel lautet kurzer

α(∆′(σ)) ⊆ ∆(α(σ))

Mit anderen Worten, jeder Zustandsubergang der konkreten Maschine ∆′ kann alsUbergang der abstrakten Maschine ∆ interpretiert werden.

Sei I ⊆ Σ eine Zustandszusicherung auf dem Zustandsraum σ und I′ ⊆ Σ′ ei-ne Zustandszusicherung auf dem Zustandsraum Σ′; wir setzen die Gultigkeit derKoppelrelation (engl. coupling relation) Koppel-

relation(couplingrelation)

α(σ) ∈ I⇔ σ ∈ I′

voraus. Dann ist I′ eine Invariante fur das Zustandsubergangssystem ∆′ unter derVoraussetzung, dass I eine Invariante fur den Zustandsubergang ∆ ist. Das lasst sichleicht wie folgt beweisen:

Sei I eine Invariante fur die Zustandsmaschine (∆, Σ0). Wir nehmen an, dass

σ′ ∈ Σ′0

dann gilt

α(σ′) ∈ Σ0

und – da I eine Invariante fur (∆,Σ0) ist – gilt weiter

α(σ′) ∈ I

Durch die Koppelrelation erhalten wir

σ′ ∈ I′

Nehmen wir an, dass σ ∈ I′ und deshalb durch die Koppelrelation

α(σ) ∈ I

18. Marz 2014 209


wenn

σ′ ∈ ∆′(σ),

dann gilt durch die Abstraktionseigenschaft

α(σ′) ∈ ∆(α(σ))

Da I eine Invariante ist, erhalten wir

α(σ′) ∈ I

und deshalb (durch die verknupfende Beziehung)

σ′ ∈ I′

Wir geben nachstehend ein einfaches Beispiel fur die Abstraktion fur Zustandsma-schinen.

Beispiel 8.4: Abstraktion eines AutomatenWir betrachten wieder das Beispiel einer Ampel. Der Zustandsraum der konkretenMaschine ist

KState = AutoAmpel× FußgangerAmpelAutoAmpel = {grun, gelb, rot, gelbgrun}FußgangerAmpel = {grun, rot}

Abb. 8.4 zeigt das Ubergangsdiagramm ∆K .

(gelbgrün, rot)

(rot, rot)(grün, rot)

(gelb, rot) (rot, grün)

Abb. 8.4.: Ampel mit Zustandsubergangen

Der abstrakte Automat hat nur drei Zustande:

AState = A× F mit A = {g, ng} und F = {g, r}

210 18. Marz 2014


Abb. 8.5.: Abstraktes Zustandsdiagramm

Sein Zustandsubergangsdiagramm ∆A ist in Abb. 8.5 gegeben.Wir definieren die Funktion

α : KState→ AState

durch die folgende Tabelle:

(a,b) grun rotgrun (g, g) (g, r)gelb (ng, g) (ng, r)rot (ng, g) (ng, r)gelbgrun (ng, g) (ng, r)

Wir erhalten

σ′ ∈ ∆K(σ)⇒ α(σ′) ∈ ∆A(α(σ))

und die gekoppelte Invarianten

IK = {(a, b) | ¬(a = grun ∧ b = grun)}IA = {(a, b) | ¬(a = g ∧ b = g)}

Aufgrund der Konstruktion genugt es, die Invariante fur den abstrakten Automatzu zeigen. 2

Das zeigt, dass wir Invarianten fur konkretere Systeme mit komplexeren Zustandenbeweisen konnen, indem wir Invarianten fur einfachere, abstrakte Systeme beweisen.Dies demonstriert auch die Idee, dass es eine abstrakte Zustandsmaschine fur einenabstrakten Zustandsraum gibt, wenn eine konkrete Zustandsmaschine gegeben ist.

Ein Spezialfall der Verfeinerung von Zustansmaschinen ist die Einfuhrung einerHilfsvariable (Geistervariable) im Sinn von [OG76]. Die Zustandsmaschine mit denzusatzlichen Hilfsvariablen ist die konkrete Maschine und die ursprungliche ist dieabstrakte Maschine. Auf diese Weise konnen wir komplexere Sicherheitseigenschaf-ten erfassen, die nicht direkt durch Invarianten der abstrakten Maschine aber alsInvarianten fur die konkrete Maschine formuliert werden konnen.

18. Marz 2014 211


Im Allgemeinen gibt es naturlich Invarianten I′ fur das konkrete System (∆′,Σ′0),die durch eine gegebene Abstraktionsfunktion α auf die Mengen {α.σ′ : σ′ ∈ I′}abgebildet werden, welche keine Invarianten fur das abstrakte System ∆ sind. Wirkonnen solche Abstraktionen der Zustandsubergangssysteme nutzen, um Gegenbei-spiele fur Formeln zu suchen, die Invarianten sein sollen. Nehmen wir an, dass diegleiche Konstruktion wie oben gegeben ist, aber nicht I, sondern I′ eine Invarianteist (oder sein soll). Dann konnen wir durch Model Checking Gegenbeispiele zu derBehauptung erzeugen, dass I eine Invariante ist, vorausgesetzt, dass die abstrakteZustandsmaschine klein genug ist, um Modellchecking zu ermoglichen. Diese Gegen-beispiele konnen in Spuren von ∆′ ubersetzt und als Testfalle verwendet werden.

8.6. Konstruktion abstrakter Zustandsmaschinen

Mit einer geeigneten Methode konnen wir abstrakte Zustandsmaschinen fur gegebe-ne konkrete Zustandsmaschinen konstruieren. Wir betrachten zwei Zustandsraume Σund Σ′ sowie ein Zustandsubergangssystem

∆′ : Σ′ → ℘(Σ′)

mit einer Abstraktionsfunktion

α : Σ′ → Σ

Wir konstruieren eine Ubergangsfunktion

∆ : Σ→ ℘(Σ)

aus der Ubergangsfunktion ∆′ schematisch wie folgt

∆(σ) = {α(σ′′) : ∃ σ′ ∈ Σ′ : σ′′ ∈ ∆′(σ′) ∧ σ = α(σ′)}

Wir bezeichnen wieder ∆ als die abstrakte Maschine und ∆′ als die konkrete Maschi-ne. Sei I′ ⊆ Σ′ eine Invariante der konkreten Maschine ∆′. Dann ist per Definition

I = {α(σ′) : σ′ ∈ I′}

eine Invariante fur die Maschine ∆. Wir beweisen dies wie folgt: Angenommen

σ1 ∈ I

Das bedeutet, dass ein Zustand σ′1 mit

α(σ′1) = σ1.

existiert. Wenn σ2 ∈ ∆(σ1) gilt, dann existieren Zustande σ′1, σ′′2 sodass

σ2 = α(σ′′2) and σ′′2 ∈ ∆′(σ′1) and σ1 = α(σ′1)

212 18. Marz 2014

8.6. Konstruktion abstrakter Zustandsmaschinen

Da σ′1 ∈ I′ und I′ eine Invariante ist, erhalten wir σ′′2 ∈ I′, und uber die Definitionvon I erhalten wir σ2 ∈ I und σ2 = α(σ′′2).

Wenn wir nur die Sicherheitseigenschaften betrachten, konnen wir tatsachlich im-mer mit der reflexiven transitiven Hulle ∆∗ eines Zustandsubergangssystems ∆ ar-beiten.

Mit dieser Methode erhalten wir die folgenden Abstraktionen entsprechend demGeheimnisprinzip:

� Abstraktion von der Granularitat der Zustandsanderung; bei zustandsbasier-ten Systemen arbeiten wir mit

”stuttering“, um Systeme mit verschiedenen

fein granulierten Zustandsanderungen verknupfen zu konnen;

� Abstraktion vom lokalen Zustand;

� Abstraktion von Implementierungszustanden der Puffer.

Man beachte, dass wir auf der Ebene historischer Sicherheitseigenschaften die Gra-nularitat der Zustandsanderungen vollstandig wegabstrahieren. Ist eine Ausgabe-Historie y ∈ ~O

∗mit

H(y)

gegeben, dann ist jede Strombelegung y′ ∈ ~O∗

mit y v y′ ein”Zustandsubergang“,

vorausgesetzt, dass H[yy′] gilt. Dies hangt mit der Beobachtung zusammen, dasswir fur jede Zustandsubergangsrelation ∆ dieselben Sicherheitseigenschaften fur ∆and ihre reflexive transitive Hulle ∆∗ erhalten.

Beispiel 8.5: Konstruktion abstrakter ZustandsmaschineGegeben sei die Maschinen

∆′ : Σ′ → ℘(Σ′) Σ′ = N∆ : Σ′ → ℘(Σ) Σ = Bα : Σ′ → Σ

mit

∆′(n) = {n+ 1}α(n) = even(n)

Wir konstruieren

∆(b) = {α(n′′) : ∃n′ ∈ N : n′′ ∈ ∆′(n′) ∧ b = α(n′)}

und erhalten

∆(b) = {¬b}2

Im obigen Beispiel existieren nur triviale Invariante.

18. Marz 2014 213


8.7. Historische Bemerkung zur Verfeinerung von Systemen

Die Idee der Verfeinerung von Programmen und Systemen findet sich bereits fruhin der sequenziellen Programmierung durch N. Wirth, C.A.R. Hoare, E. Dijkstraund O.-J. Dahl. Diese Idee lasst sich grundsatzlich auf nebenlaufige Systeme erwei-tern. Schon in den 70er Jahren finden sich erste Uberlegungen zur Verfeinerung, diedann in einer Fulle von Arbeiten fur die unterschiedlichsten Ansatze zur Systemmo-dellierung weiter entwickelt wurden. Allerdings gibt es hier eine starke Diskrepanzzwischen den eher theoretischen Arbeiten, die auf Basis eines genau festgelegten lo-gischen Ansatzes einen Verfeinerungskalkul fur verteilte Systeme entwickelt haben,wie beispielsweise die Arbeiten von C.A.R. Hoare (vgl. z.B. [DDH72]), M. Hennessy(vgl. [AH94]) und Hehner (vgl. [Heh93]) zum einen und den starker pragmatischenArbeiten, in denen sich zwar auch ahnliche Ideen finden, beispielsweise unter demStichwort der Design Patterns (vgl. [GHJV95]), wo aber oft vollig auf eine formaleFundierung verzichtet wurde. Es bleibt der Zukunft uberlassen, die beiden Ansatzenoch starker zueinander in Beziehung zu setzen und zu zeigen, dass die theore-tischen Verfeinerungsansatze die Grundlage bilden konnen fur die pragmatischenVorgehensweisen.

Besonders bedeutsam ist es in diesem Zusammenhang, die wichtigen Technikendes Wechsels der Abstraktionsebenen, wie wir sie in vielen praktischen Ansatzenzur Systementwicklung finden, mit einem sauberen formalen Fundament zu unter-legen. Im vorangegangen Kapitel wurde dies inbesondere unter dem Stichwort der

”U-Simulation“ und der

”Abstraktions- bzw. Reprasentationsverfeinerung“ abge-

handelt.

214 18. Marz 2014

9. Zeitmodellierung

Bisher haben wir nur Systemmodelle betrachtet, bei denen quantitative Zeit, also diezeitliche Dauer von Aktionen und auch von Kommunikationsaktionen, wie etwa denzeitlichen Abstand zwischen Eingabe und Reaktion, oder zwischen der Ausfuhrungvon Aktionen, keine Rolle gespielt hat. Fur viele Anwendungen, insbesondere fureingebettete Systeme, sind Fragen der quantitativen Zeit von besonderer Bedeutung.Man spricht dabei von Echtzeitsystemen.

Explizite Zeitmodelle benotigen wir zur Darstellung folgender Verhaltensmusterin interaktiven und reaktiven Systemen:

� sofortige Unterbrechung (mit Fortsetzung oder endgultigem Abbruch) einerAktivitat,

� Reaktion beim Ablauf von Zeitschranken (Time-Out),

� Reaktion auf Ereignisse innerhalb von Zeitschranken,

� Ein- oder Ausgabe von Nachrichten in bestimmten minimalen oder maximalenZeitabstanden (zyklische Ereignisse mit vorgegebener Nachrichtenfrequenz).

Solche Konzepte konnen ohne einen expliziten Zeitbegriff nicht in Systemen erfasstwerden. Es gibt eine ganze Reihe unterschiedlicher Zeitmodelle. In der elementarstenKlassifizierung unterscheiden wir analoge,

”kontinuierliche“ Zeit (Zeit wird durch

eine reale Zahl dargestellt) und diskrete Zeit (Zeit wird durch eine naturliche Zahl kontinuierlichediskreteZeit

dargestellt). Wir betrachten im Weiteren allerdings nur diskrete Zeit.Zur Erfassung quantitativer Zeiteigenschaften von Systemen konnen wir folgende

unterschiedliche Zeitmodelle einsetzen:

� diskrete Zeit (Zeit, dargestellt durch die ganzen oder die naturlichen Zahlen),

� kontinuierliche Zeit (Zeit, dargestellt durch die reellen Zahlen).

Fur kontinuierliche Zeit konnen wir mit kontinuierlichen Nachrichten- oder Zu-standsstromen (diese entsprechenden klassischen stetigen Funktionen der mathema-tischen Analysis) arbeiten, oder mit diskreten Datenstromen, die mit Zeitstempelversehen sind. In Modellen kontinuierlicher Zeit auftretende kontinuierliche Nach-richtenstrome entsprechen reellen Funktionen, die von durch eine reelle Zahl darge-stellten Zeitparametern abhangig sind. Diese werden in der klassischen Mathematik(Differential- und Integralrechnung), in der Physik und in der Regelungstechnik be-trachtet. Wir behandeln abschließend ausschließlich ein einfaches Modell diskreterZeit.

18. Marz 2014 215

Kapitel 9. Zeitmodellierung

9.1. Ein einfaches diskretes Zeitmodell

In diesem Abschnitt fuhren wir ein einfaches Systemmodell mit diskreter Zeit ein.In diesem Modell betrachten wir Strome, die neben den Elementen der ihnen zuge-ordneten Sorte das spezielle Signal

√, genannt Zeittick, enthalten. Es zeigt jeweilsZeittick

das Ende eines Zeitintervalls an. Solche Strome nennen wir gezeitete Strome undgezeiteterStrom geben ihnen die Sorte

Tstream α

wobei α die Sorte der Nachrichten in den gezeiteten Stromen bezeichnet.Wir fordern dabei, dass jeder unendlich gezeitete Strom eine unendliche Anzahl

von Zeitticks enthalt. Da zeitbehaftete Strome damit ein Spezialfall allgemeinerStrome sind, steht der gesamte Begriffsapparat, den wir fur Strome eingefuhrt haben,weiterhin zur Verfugung.

Wir geben ein Beispiel fur die Beschreibung eines Systems auf gezeiteten Stromen,eine Weckerkomponente, genannt Timer (Zeitgeber).

Beispiel 9.1: Der ZeitgeberDie Schnittstelle des Zeitgebers ist in der Abb. 9.1 dargestellt. Wir beschreiben denZeitgeber als Zustandsmaschine. Der Zustandsraum des Systems ist gegeben durchdas Attribut

c: Nat

das die Zeit anzeigt, nach der der Zeitgeber ein Zeitsignal (Weckruf, Alarm) absetzt.Falls c = 0 gilt, ist der Zeitgeber nicht aktiviert. Das Verhalten des Zeitgebers istdurch die Zustandsmaschine in Abb. 9.2 angegeben (sei x ∈ Nat).

Mit dem Signal√

bezeichnen wir ein Ticken der (globalen) Uhr. Dabei definierenwir zwei Sorten

type Tin = Tstream (Nat ∪ {undo})

type Tout = Tstream Event

wobei

type Event = {alarm}

Die Kontrollzustande der Zustandsmaschine entsprechen den folgenden Pradikatenauf den Zustandsraum:

Not set: c = 0Set: c > 0

Dieses Beispiel benutzt die globale Zeit zur Modellierung des Zeitverhaltens.

216 18. Marz 2014

9.2. Zeitsynchrone Systeme

Timer

c: Naty: Tout

x: Tin

Abb. 9.1.: Schnittstelle des Zeitgebers

Not_set Set

c := 0 √ c = 0x c = x

undo c = 0

c = 0 √ alarm c = 0

c > 0 √ c = c - 1

x c = x

Abb. 9.2.: Zustandsubergangsdiagramm fur den Zeitgeber

2

Zeitkritische Komponenten konnen wir durch Funktionen (oder Relationen) auf zeit-behafteten Stromen modellieren. Damit diese Komponenten den Zeitfluss realistischwiedergeben, mussen sie folgende Bedingung erfullen.

Korrekter Zeitfluss: Die Ausgaben bis zum Zeitpunkt i (bei Komponentemit Zeitverzogerung i+ 1) hangen nur von den Eingaben bis zu Zeitpunkt i ab.

Diese Eigenschafts formalisieren wir nachstehend unter dem Stichwort”starke Kau-

salitat“. Abgesehen von diesen speziellen Eigenschaften des Zeitflusses konnen In-formationen uber die Zeit wie beliebige andere Informationen behandelt werden.

9.2. Zeitsynchrone Systeme

Zeitsynchrone Systeme verfugen uber einen globalen”absoluten“ Zeitbegriff, der

das Zeitverhalten aller Teilkomponenten global zueinander in Beziehung setzt. DasFortschreiten der Zeit findet fur alle Teilsystemen einheitlich,

”synchron“, statt. Ein

einfaches Modell dafur erhalten wir, indem wir eine globale Variable einfuhren, diedie Zeit darstellt und die wir Schritt um Schritt erhohen (vgl. [Lam94]).

Diskrete Zeit fuhrt dabei ein Zeitraster ein, in das die Aktionen eines Systemseingeordnet werden. Nehmen wir an, dass jede Aktion und jedes Ereignis einen Punkt

18. Marz 2014 217


in der Zeit darstellt, und dass kein Ereignis genau mit dem Ende eines Zeitintervallszusammenfallt, so entsteht ein Zeitraster von Zeitpunkten, so dass zwischen zweiaufeinander folgenden Zeitpunkten ein Prozess von Aktionen liegt. Wir sprechenbeim Zeitraster von einem Makrotakt und bei der Folge von Aktionen in einemProzess zwischen zwei aufeinander folgenden Zeitpunkten von dem Mikroprozess.

9.2.1. Zeitsynchrone, nachrichtenasynchrone Systeme

Wie oben gezeigt, konnen wir einen einfachen Zeitbegriff einfuhren, der Systeme miteiner diskreten,

”globalen“ Zeit versieht. Wir nennen ein System zeitsynchron und

nachrichtenasynchron, wenn ein einheitlicher (globaler) Zeitbegriff existiert, aberder Nachrichtenaustausch asynchron erfolgt und in einem Zeitinterval beliebig vieleNachrichten auf einem Kanal ausgetauscht werden konnen.

Wir konnen dabei Systeme mit schwacher und starker Kausalitat unterscheiden.Wir spezifizieren ein System als stromverarbeitende Funktion F.

Definition: Starke KausalitatstarkeKausalitat Wir nennen ein System F stark kausal, wenn fur alle Eingabehistories x und y von

F folgendes gilt: Sind die Eingabehistories x und y bis zum Zeitpunkt t identisch,so sind auch die entsprechende Ausgabehistories F(x) und F(y) identisch bis zumZeitpunkt t+ 1. 2

Starke Kausalitat entspricht der Situation, dass ein System um mindestens eine Zeit-einheit verzogert auf Eingabe reagiert.

Definition: Schwache KausalitatschwacheKausalitat Wir nennen ein System F schwach kausal, wenn fur alle Eingabehistories x und y von

F folgendes gilt: Sind die Eingabehistories x und y bis zum Zeitpunkt t identisch, sosind auch die entsprechende Ausgabehistories F(x) und F(y) identisch bis zu diesemZeitpunkt t. 2

Schwache Kausalitat erfasst die Erfordernisse eines Logischen Zeitflusses. Eine Re-aktion auf Eingaben kann nicht fruher erfolgen als die Ausgabe.

Beispiel 9.2: Nichtkausale KomponenteEine nichtkausale Komponente erhalten wir durch folgende Beschreibung

f : (N ∪ {√})∞ → (N ∪ {

√})∞

mit (sei s, s′ ∈ N∗):

f(s〈√〉s′〈√〉x) = ss′〈√〉f(x)

Die Funktion loscht jeden zweiten Timetick√

. Nimmt man die Timeticks als Zeitan-gaben, so erhalten wir die Ausgabe schließlich viel Fruher als sie eingegeben werden.

2

218 18. Marz 2014

9.3. Perfekte Synchronie

9.2.2. Zeitsynchrone, nachrichtensynchrone Systeme

In zeitsynchronen, nachrichtensynchronen Systemen existiert ein einheitlicher (glo-baler) Zeitbegriff. Der Nachrichtenaustausch erfolgt synchron. In jedem Zeitintervallwird auf jedem Kanal genau eine Nachricht ausgetauscht. Dies entspricht einem ein-fachen Modell fur Schaltwerke und Schaltnetze.

Beispiel, Zusammenhang Kausalitat

9.3. Perfekte Synchronie

In der perfekten Synchronie (engl.”perfect synchrony“) existiert ein einheitlicher

(globaler) Zeitbegriff. Pro Zeiteinheit wird eine Menge von Nachrichten ausgetauscht,die im gleichen Zeitfenster verarbeitet werden. Wir sprechen auch von einer Mengevon Ereignissen. Damit geht zwar der Begriff der Kausalitat zwischen den Ereignis-sen innerhalb eines Zeitfensters verloren, fur bestimmt Arten von Systemen entstehtso aber eine sehr brauchbare Abstraktion. In den letzten zwei Jahrzehnten entstandsogar die ganze Familie synchroner Sprachen, wie beispielweise Esterel (vgl. [Ber00]).

9.4. Historische Bemerkung zur Zeitmodellierung

Das Thema der Zeit im Sinne von Berechnungszeit und Antwortzeiten (”Echtzeit“)

von Systemen der Informatik hat fur praktische Systeme immer eine grosse Be-deutung gehabt. Interessanterweise waren fruhe akademische Arbeiten allerdingsbemuht, von Zeitbegriffen zu abstrahieren und Modelle fur das Verhalten von Syste-men zu entwickeln, in denen Zeit keine maßgebliche Rolle spielt. Die Grunde hierfurliegen auf der Hand. Ziel war es, Systemverhalten von den Besonderheiten einerRechenanlage, insbesondere von der Verarbeitungsgeschwindigkeit, weitgehend un-abhangig zu beschreiben. Da gerade das Zeitverhalten stark von den individuellenGeschwindigkeiten der Prozessoren und der Ausfuhrung von Kommandos beeinflusstwar, wollte man von diesen Fragestellungen vollig abstrahieren.

Die Programmierung echtzeitkritischer Systeme wurde hingegen eher unter prag-matischen Vorzeichen betrieben. Es gab dazu vergleichsweise wenig theoretischeAnsatze. Typischerweise war Echtzeitprogrammierung ein Handwerk, bei dem manim ersten Ansatz Programme schrieb, dann deren Realzeitverhalten am Rechneruberprufte und in Fallen, wo das gewunschte Antwortzeitverhalten mit den aus derAnwendung sich ergebenden Forderungen nicht in Einklang zu bringen war, durchOptimierung und entsprechende Anderungen des Systems schließlich zu einem ak-zeptablen System zu gelangen suchte.

Solange man – wie dies typisch fur Aufgaben der Kontroll- und Reglungstechnik ist– mit einfachen, nicht vernetzten Fragestellungen konfrontiert war, war diese Vorge-hensweise im Wesentlichen zielfuhrend, wenn auch aufwandig und stark auf Versuch

18. Marz 2014 219


und Irrtum ausgerichtet. Gerade zyklische Systeme, wie sie in der Regelungs- undKontrolltheorie haufig auftreten, bei denen zu fest vorgegebenen Zeitpunkten Sensor-werte gelesen werden und in bestimmten Zeitabstanden in Aktuatorwerte umgesetztwerden, sind so noch beherrschbar. In heutigen Systemen, wo eine starke Vernetzungund eine hohe Komplexitat gegeben ist, ist die Notwendigkeit geeigneter Abstrak-tionen fur die Zeitmodellierung stark gestiegen. Aus diesem Grund heraus gibt esheute ein reges Interesse an einer gerade fur das zeitliche Verhalten theoretischenBehandlung von Echtzeit.

Nach ersten Ansatzen zur Darstellung von Echtzeit als Teil von denotationel-len Modellen (vgl. [Bro83]) sind eine Reihe von Verfahren um Zeitaspekte erwei-tert worden. Typisch sind dabei Ansatze, in denen gangige, Beschreibungsverfah-ren fur verteilte Systeme um Zeitaspekte erweitert worden. Beispiele dafur sindTLA, in denen uber einfache Programmvariable, die den Fortschritt der Zeit mes-sen, Echtzeitaufgaben im gleichen formalen Rahmen erledigt werden konnen (vgl.[Lam78, Lam84, Lam94]).

Weitergehende Ansatze sind Statecharts (vgl. [Har87, HP98, NRS96, PS97a, PS97b,Sch96, SNR97]), die in einer ersten Version mit einem sehr konkreten Zeitmodell ver-sehen sind. Dieses Zeitmodell ist allerdings sehr komplex und in vielen praktischenSituationen kaum gewinnbringend einsetzbar.

Ein konsequenter Ansatz ist die so genannte perfekte Synchronitat, bei der –ahnlich ubrigens zu gewissen Ansatzen in Statecharts – bestimmte Zeitabstraktionenvorausgesetzt werden, so dass die Zeit in sehr grobe Segmente unterteilt wird, indenen Mengen von Einzelereignissen zusammengefasst werden.

Daneben ist eine Reihe sehr ausgefeilter Zeitmodelle entstanden. Wichtige Bei-spiele dafur sind die so genannten Timed Automata von Alur und Henzinger (vgl.[AFH94]) oder der Duration Calculus (vgl. [ZHR91]), in dem besonderes Gewichtdarauf gelegt wird, uber die zeitliche Dauer zu argumentieren, die eine bestimm-te Bedingung in einem System gegeben ist. Dies ist insbesondere fur eingebetteteSysteme, die physikalische Prozesse steuern, von Bedeutung, da dadurch beispiels-weise gemessen werden kann, wie viel Treibstoff uber einen bestimmten Zeitraumverbraucht worden ist oder wie viel Brennstoff einem Brenner zugefuhrt worden ist.

Eine starker formale und methodische Fundierung von Zeitmodellen und ihrersystematischen Nutzung ist eine Aufgabe fur die Zukunft. Eine besondere Heraus-forderung ist dabei nach wie vor das Zusammenfuhren von diskreten und analogenZeitmodellen sowie die Kombination von Vorgehensweisen der Steuerungs- und Re-gelungstechnik mit denen der Theorie verteilter Systeme auch wenn inzwischen erstetheoretische Beitrage dazu existieren (vgl. die Dissertation [Sta01]).

220 18. Marz 2014

Literaturverzeichnis

[AFH94] R. Alur, L. Fix, and T.A. Henzinger. Event-clock automata: A determi-nizable class of timed automata. In Proceedings of the Sixth Conferenceon Computer-Aided Verification, volume 818 of Lecture Notes in Com-puter Science, pages 11–13. Springer Verlag, 1994.

[AH90] H. Agrawal and J. R. Horgan. Dynamic program slicing. In PLDI ’90:Proceedings of the ACM SIGPLAN 1990 conference on Programminglanguage design and implementation, pages 246–256, New York, NY,USA, 1990. ACM Press.

[AH94] L. Aceto and M. Hennessy. Adding action refinement to a finite processalgebra. Inf. Comput., 115(2):179–247, 1994.

[AL91] M. Abadi and L. Lamport. The existence of refinement mappings. The-or. Comput. Sci., 82(2):253–284, 1991.

[AR02] F. Arbab and J. J. M. M. Rutten. A coinductive calculus of componentconnectors. Technical Report SEN-R0216, Centrum voor Wiskunde enInformatica (CWI), Amsterdam, 2002.

[AW76] E. A. Ashcroft and W. W. Wadge. Lucid – a formal system for writingand proving. SIAM Journal on Computing, 5(3):336–354, September1976.

[BD00] B. Bruegge and A.H. Dutoit. Object-oriented Software Engineering:Conquering Complex and Changing Systems. Prentice Hall, 2000.

[BDD+92] M. Broy, F. Dederich, C. Dendorfer, M. Fuchs, T. Gritzner, and R. We-ber. The design of distributed systems - an introduction to focus. Tech-nical Report TUM-I9202, Technische Univeritat Munchen, 1992.

[Ber00] G. Berry. The Foundations of Esterel. MIT Press, 2000.

[BG93] O. Bernholtz and O. Grumberg. Branching time temporal logic andamorphous tree automata. In E. Best, editor, CONCUR’93: Proc. ofthe 4th International Conference on Concurrency Theory, pages 262–277. Springer, Berlin, Heidelberg, 1993.

18. Marz 2014 221


[BG94] A. Blass and Y. Gurevich. Evolving algebras and linear time hierarchy.In B. Pehrson and I. Simon, editors, IFIP 1994 World Computer Con-gress, volume I: Technology and Foundations, pages 383–390. ElsevierScience Publishers, 1994.

[Bro83] M. Broy. Applicative real time programming. In Information Processing83, IFIP World Congresslncs, pages 259–264, Paris, 1983. North HollandPubl. Company.

[Bro91] M. Broy. Towards a formal foundation of the specification and descrip-tion language SDL. Formal Aspects of Computing, 3(1):21–57, 1991.

[Bro93] M. Broy. (Inter-)Action Refinement: The Easy Way, volume 118 ofSeries F: Computer and System Sciences. Springer NATO ASI Series,1993.

[BS01a] J. Bradfield and C. Stirling. Modal logics and mu-calculi: an introducti-on. In A. Ponse J. Bergstra and S. Smolka, editors, Handbook of ProcessAlgebra. Elsevier, North-Holland, 2001.

[BS01b] M. Broy and K. Stølen. Specification and Development of Interacti-ve Systems: Focus on Streams, Interfaces, and Refinement. SpringerVerlag, 2001.

[BSL99] A. Blume, G. Siebert, and R. Linz. Projektkompass SAP. Vieweg Verlag,1999.

[Bur97] R. Burkhardt. UML: Unified Modeling Language. Addison-Wesley,1997.

[BVW94] O. Bernholtz, M.Y. Vardi, and P. Wolper. An automata-theoretic ap-proach to branching-time model checking. In D. L. Dill, editor, Compu-ter Aided Verification, Proc. 6th Int. Conference, volume 818 of LectureNotes in Computer Science, pages 142–155, Stanford, June 1994. Sprin-ger Verlag.

[CGP99] E.M. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press,1999.

[CM88] K.M. Chandy and J. Misra. Program Design: A Foundation. Addison-Wesley, 1988.

[DBkCL80] J.B. Dennis, G.A. Boughton, and C. k C. Leung. Building blocks fordata flow prototypes. In 7th Annual Symposium on Computer Archi-tecture, La Boule, France, 1980.

222 18. Marz 2014


[DDH72] O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. Structured Programming.Academic Press, London New York, 1972.

[DeM79] T. DeMarco. Structured Analysis and System Specification. YourdonPress Computing Series. Prentice Hall, New York, 1979.

[Den74] J.B. Dennis. First version of a data flow procedure language. In Pro-ceedings, Colloque sur la Programmation, pages 362–376, Paris, France,1974.

[Dij65] E.W. Dijkstra. Solution of a problem in concurrent programming con-trol. Communications of the ACM, 8(9):569, 1965.

[DN65] O.-J. Dahl and K. Nygaard. SIMULA: A Language for Programmingand Description of Discrete Event Systems. Norwegian Computing Cen-ter (NCC), Oslo, May 1965. Introduction and User’s Manual.

[FT01] J.L. Fernandez and A. Toval. Seamless formalizing the UML semanticsthrough metamodels. In K. Siau and T. Halpin, editors, Unified Mo-deling Language: Systems Analysis, Design, and Development Issues,pages 224–248. Idea Group Publishing, 2001.

[GAO95] D. Garlen, R. Allen, and J. Ockerbloom. Architectural mismatch: Whyreuse is so hard. IEEE Software, pages 17–26, November 1995.

[GB99] I. Jacobson G. Booch, J. Rumbaugh. The Unified Modeling LanguageUser Guide. Addison Wesley, 1999.

[GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns:elements of reusable object-oriented software. Addison-Wesley LongmanPublishing Co., Inc., Boston, MA, USA, 1995.

[GS93] D. Gries and F.B. Schneider. A Logical Approach to Discrete Mathe-matics. Springer Verlag, 1993.

[Gur94] Y. Gurevich. Evolving algebras. In B. Pehrson and I. Simon, editors,IFIP 1994 World Computer Congress, volume I: Technology and Foun-dations, pages 423–427. Elsevier Science Publishers, 1994.

[Han78] P.B. Hansen. Distributed processes: A concurrent programming con-cept. Communications of the ACM, 21(11):934–941, 1978.

[Han87] P.B. Hansen. Joyce – A programming language for distributed systems.Softw. Pract. Exper., 17(1):29–50, 1987.

[Har87] D. Harel. Statecharts: A visual formalism for complex systems. Scienceof Computer Programming, 8(3):231–274, June 1987.

18. Marz 2014 223


[HB05] D. Herzberg and M. Broy. Modeling layered distributed communicationsystems. Formal Asp. Comput., 17(1):1–18, 2005.

[Heh93] E.C.R. Hehner. A Practical Theory of Programming. Springer Verlag,1993.

[Hel91] G. Held. GRAPES Language Description. Syntax, Semantics andGrammar of GRAPES-86. Siemens Nixdorf Inform, Berlin, 1991.

[Hoa74] C.A.R. Hoare. Monitors – an operating system structuring concept.Communications of the ACM, 17(10):549–557, Nov. 1974.

[Hoa76] C.A.R. Hoare. Parallel programming: An axiomatic approach. Comput.Lang., 1(2):151–160, 1976.

[Hoa78] C.A.R. Hoare. Communicating sequential processes. Communicationsof the ACM, 21(8):666–677, Nov. 1978.

[Hoa85a] C.A.R. Hoare. Communicating sequential processes. Prentice Hall, 1985.

[Hoa85b] C.A.R. Hoare. Notes on communicating systems. In M. Broy, editor,Control Flow and Data Flow: Concepts of Distributed Programming.Proceedings of NATO Advanced Study Institute International SummerSchool, Marktoberdorf, 31 July - 12 August, 1984, pages 123–204. Sprin-ger Verlag, 1985.

[HP98] D. Harel and M. Politi. Modeling Reactive Systems with Statecharts:The STATEMATE Approach. McGraw-Hill, 1998.

[Jac83] M. A. Jackson. System Development. Prentice Hall, 1983.

[JR97] B. Jacobs and J. Rutten. A tutorial on (co)algebras and (co)induction.Bulletin of the EATCS, 62:222–259, 1997.

[KM77] G. Kahn and D.B. MacQueen. Coroutines and Networks of ParallelProcesses. In IFIP 77. North Holland, 1977.

[Kro87] F. Kroger. The Temporal Logic of Programs. Springer Verlag, 1987.

[Lam78] L. Lamport. Time, clocks, and the ordering of events in a distributedsystem. Commun. ACM, 21(7):558–565, 1978.

[Lam84] L. Lamport. Using time instead of timeout for fault-tolerant distributedsystems. ACM Trans. Program. Lang. Syst., 6(2):254–280, 1984.

[Lam94] L. Lamport. The temporal logic of actions. ACM Transactions onProgramming Languages and Systems, 16(3):872–923, May 1994.

224 18. Marz 2014


[LKA+95] D.C. Luckham, J.L. Kenney, L.M. Augustin, J. Vera, D. Bryan, andW. Mann. Specification and analysis of system architecture using rapi-de. IEEE Transactions on Software Engineering, 21(4):336–355, 1995.

[LSVW96] N.A. Lynch, R. Segala, F.W. Vaandrager, and H.B. Weinberg. Hy-brid I/O automata, Hybrid System III, volume 1066 of Lecture Notes inComputer Science. Springer Verlag, 1996.

[Mil80] R. Milner. A Calculus of Communicating Systems, volume 92 of LectureNotes in Computer Science. Springer Verlag, Berlin, 1980.

[Mil89] R. Milner. Communication and Concurrency. Prentice Hall, 1989.

[Mil99] R. Milner. Communicating and mobile systems: the pi-calculs. Cam-bridge University Press, 1999.

[MP92] Z. Manna and A. Pnueli. A Temporal Logic of Reactive Systems andConcurrent Systems. Springer Verlag, 1992.

[MS92] R. Milner and D. Sangiorgi. Barbed bisimulation. In Proceedings ICALP’92, volume 623, pages 685–695, Vienna, 1992. Springer Verlag.

[Nag99] M. Nagl. Softwaretechnik mit Ada – Entwicklung großer Systeme. View-eg Verlag, 1999.

[NRS96] D. Nazareth, F. Regensburger, and P. Scholz. Mini-Statecharts: A LeanVersion of Statecharts. Technical Report TUM-I9610, Technische Uni-versitat Munchen, 1996.

[OG76] S. Owicki and D. Gries. Verifying properties of parallel programs: anaxiomatic approach. Communications of the ACM, 19(5):279–285, 1976.

[Par92] D.L. Parnas. Tabular representation of relations. CRL Report 260, Mc-Master University, Communications Research Laboratory, TRIO (Tele-communications Research Institute of Ontario), October 1992.

[Pet62] C.A. Petri. Kommunikation mit automaten. Technical Report RADC-TR-65–377, Bonn, Institut fur Instrumentelle Mathematik, 1962.

[Pet63] C.A. Petri. Fundamentals of a theory of asynchronous informationflow. In Proc. of IFIP Congress 62. – Amsterdam: North Holland Publ.Comp., pages 386–390, 1963.

[PS97a] J. Philipps and P. Scholz. Compositional specification of embedded sys-tems with statecharts. In TAPSOFT’97: Theory and Practice of Soft-ware Development, Lecture Notes in Computer Science 1214. SpringerVerlag, 1997.

18. Marz 2014 225


[PS97b] J. Philipps and P. Scholz. Formal verification of statecharts with in-stantaneous chain reactions. In TACAS’97: Tools and Algorithms forthe Construction and Analysis of Systems, Lecture Notes in ComputerScience 1217, pages 224 – 238. Springer Verlag, 1997.

[Rei90] W. Reisig. Petrinetze – eine Einfuhrung. Springer Verlag, 1990.

[Ros77] D.T. Ross. Structured analysis (sa): A language for communicatingideas. IEEE Trans. Software Eng., 3(1):16–34, 1977.

[Ros90] D.T. Ross. Applications and extensions of sadt. In E. P. Glinert, edi-tor, Visual Programming Environments: Paradigms and Systems, pages147–156. IEEE Computer Society Press, Los Alamitos, 1990.

[SAdBB03] J.G. Scholten, F. Arbab, F.S. de Boer, and M.M. Bonsangue. A channel-based coordination model for components. Electr. Notes Theor. Com-put. Sci., 68(3), 2003.

[Sch96] P. Scholz. An Extended Version of Mini-Statecharts. Technical ReportTUM-I9628, Technische Universitat Munchen, 1996.

[Sch97] F. Schneider. On Concurrent Programming. Springer Verlag, 1nd edi-tion, 1997.

[Sei02] H. Seidlmeier. Prozessmodellierung mit ARIS. Eine beispielorientierteEinfuhrung fur Studium und Praxis. Vieweg Verlag, 2002.

[SJ02] A.-W. Scheer and W. Jost. ARIS in der Praxis. Gestaltung, Imple-mentierung und Optimierung von Geschaftsprozessen. Springer Verlag,2002.

[SN00] A.-W. Scheer and M. Nuttgens. Aris architecture and reference modelsfor business process management. In Business Process Management,Models, Techniques, and Empirical Studies, pages 376–389, London,UK, 2000. Springer Verlag.

[SNR97] P. Scholz, D. Nazareth, and F. Regensburger. Mini-statecharts: A com-positional way to model parallel systems. In in: K. Yetongnon, S. Hariri(Eds.), Proceedings of the Ninth International Conference on Paralleland Distributed Computing Systems, Dijon, France, 1997.

[Spi98] K. Spies. Eine Methode zur formalen Modellierung von Betriebssystem-konzepten. PhD thesis, Technische Universitat Munchen, 1998.

[Sta01] T. Stauner. Systematic Development of Hybrid Systems. PhD thesis,Technische Universitat Munchen, 2001.

226 18. Marz 2014


[Ste99] Christoph Steindl. Program Slicing for Object-Oriented ProgrammingLanguages. PhD thesis, Johannes Kepler University Linz, 1999.

[Sto77] J. E. Stoy. Denotational Semantics: The Scott-Strachey Approach toProgramming Languages. MIT Press, 1977.

[Tan03] A. S. Tanenbaum. Moderne Betriebssysteme. Pearson Studium, 2003.

[Tar55] A. Tarski. A lattice-theoretical fixpoint theorem and its applications.Pacific Journal of Mathematics, 5(2):285–309, 1955.

[Thu04] V. Thurner. Formal fundierte Modellierung von Geschaftsprozessen.PhD thesis, Technische Universitat Munchen, 2004.

[Tip95] Frank Tip. A survey of program slicing techniques. Journal of program-ming languages, 3(3), September 1995.

[vB91] J. van Benthem. The Logic of Time. Kluwer Academic Publishers, 2.edition edition, 1991.

[Win89] G. Winskel. An introduction to event structures. In Linear Time,Branching Time and Partial Order in Logics and Models of Concurren-cy, volume 354 of Lecture Notes in Computer Science, pages 364–397.Springer Verlag, 1989.

[ZHR91] Zhou Chaochen, C.A.R. Hoare, and A.P. Ravn. A calculus of durations.Information Proc. Letters, 40(5), Dec. 1991.

18. Marz 2014 227


Glossar

Bisimilarity, see BisimulationCCS, see Calculus for Communicating Sys-

temsCSP, see Communicating Sequential Pro-

cesses, see Communicating Sequen-tial Processes

Calculus for Communicating Systems, 193Communicating Sequential Processes, 173,

193Event Traces, see InteraktionsdiagrammeLiveness Properties, see Lebendigkeitsbe-

dingungenMSCs, see Message Sequence ChartsMessage Sequence Charts, see Interakti-

onsdiagrammeSTD, see State Transition DiagramSTM, see State Transition MachineSafety Properties, see Sicherheitsbedingun-

genState Transition Diagram, see Zustandsuber-

gangsdiagrammState Transition Machine, see Zustands-

maschineTLA, see Temporal Logic of ActionsTemporal Logic of Actions, 76behavioural differential equations, 239busy waiting, 70co-induktiv, 239coinduction proof principle, 240communication histories, see Kommuni-

kationsgeschichtecoupling relation, see Koppelrelationenabled, see bereite Aktionoracle, see Orakelprophecy, see Orakelrefusal set, see Verweigerungsmengeshared variable, see gemeinsame Programm-

variabletrace, see AblaufTemporal Logic of Actions, see TLA

Ablauf, 22, 181responsiver, 168

schwach fair, 189stark fair, 189unvollstandiger, 156vollstandiger, 156

Ablaufpfad, 181Abstraktion, 203Adaquater Zustandsbegriff, 187Aktion

bereite, 30Aktionen, 153Aktionsspuraquivalenz, 190Aktionsstruktur, see Prozess

endlich fundierte, 155Assumption/Commitment-Spezifikation, see

Assumption/Guarantee-SpezifikationAssumption/Guarantee-Spezifikation, 101Ausgabeanweisung, 137Automat, see ZustandsmaschineAxiom

fur Ausgabekanale, 137fur Eingabekanale, 137

Berechnung, 22Bereitschaftsmenge, 184Bisimulation, 190, 240Broadcast-Ubertragung, 83

Darstellung der Zustandsmaschinenanalytische, 44graphische, 45Matrix, 48tabellarische, 45

Datenflussmodell, 111

Eingabeanweisung, 137Ereignis, 153, 154

Feedback, see Komposition: FeedbackFOCUS, 234Fortsetzung, see Resumption

Geistervariable, see Hilfsvariable

Handshake-Kommunikation, see nachrich-tensynchrone Kommunikation

228 18. Marz 2014

GLOSSAR

Hilfsvariable, 72Historie, see Ablauf

Interaktion, 4Interaktionsdiagramme, 169Interferenzen, 70Interferenzfreiheit annotierter Anweisun-

gen, 71Interleaving, 55, 60Invariante, 158

Kapselung, 3Kausalitat

schwache, 218starke, 218

Kausalitatsbeziehung, 153Kommunikation, 4

nachrichtensynchrone, 83Kommunikationsgeschichte, 234Komponente, 111Komposition

Feedback, 129parallele, 60, 117, 128sequentielle, 37, 129

Koordination, 4Koppelrelation, 209

Lebendigkeitsbedingungen, 157Logik

temporale, 76, 161

Mealy-Automat(ZM), 45Modell (eines Systems), 8Moore-Automat(ZM), 45

Nebenlaufigkeit, 4, 153asynchrone, see Interleavingsynchrone, 55

oder-Parallelitat, see InterleavingOrakel, 149, 242

Parallelitat, 4Petri-Netz, 165Pradikat

stabiles, 26Prafixordnung, 156Programme

(disjunkt) parallele, 66Programmvariable

gemeinsame, 60Prozess, 154

Ruckkopplung, 117, see Komposition: Feed-back

Reaktion, 4Rendezvous, see nachrichtensynchrone Kom-

munikationReo, 234Reprasentation, 203Reprasentationsverfeinerungspaar, 203Resumption, 106

Schnittstelle, 3, 79syntaktische, 82, 147

Schnittstellenkompatibilitat, 81Schnittstellensicht, 79Sicherheitsbedingungen, 157Slice, 73Slicing, 73Spur, see AblaufStiller Ubergang, 179Strom, 84Strom (gezeiteter), 216Stuttering, 55Synchronisationsbaum, 181System

analoges, 1diskretes, 1hybrides, 2

Teilfunktion, 201TLA, 206

und-Parallelitat, see synchrone Nebenlaufig-keit

Variableglobale (gemeinsame), 148gemeinsame, see gemeinsame Programm-

variablelokale, 148

VerfeinerungEigenschaftsverfeinerung, 199Interaktionsverfeinerung, 202

18. Marz 2014 229


Reprasentationsverfeinerung, 199Verklemmung, 180Verteilung, 3Verweigerungsmenge, 184

Wiederholungsanweisung, 38

ZUD, see ZustandsubergangsdiagrammZeit

diskrete, 215kontinuierliche, 215quantitative, 4

Zeittick, 216ZM, see ZustandsmaschineZusicherungsbeweis

interferenzfreier, 71Zustandsubergangsdiagramm, 19, 33Zustandsinvariante, 26Zustandsmaschine, 19

deterministische, 21mit Ein-/Ausgabe, 41nichtdeterministische, 20, 21nichtdeterministische, mit markierten

Ubergangen, 30partielle, 21totale, 21

230 18. Marz 2014

BEISPIELE

Beispiele

2.10 Eine Warteschlange als Zustandsmaschine mit Ein- und Ausgabe, 42

2.11 Speicherzelle, 44

2.12 Automat A1 (Deterministischer Mealy-Automat), 46

2.13 Automat A2 (Deterministischer Moore-Automat), 46

2.14 Logikbasierte Tabelle fur Speicherzelle, 47

2.15 Bahnubergang, 49

2.16 Lesen und Schreiben eines Attributs, 51

2.17 Geldautomat objektorientiert, 52

2.18 Bankkonto objektorientiert, 53

2.19 Summe und Produkt von ZM zur Modellierung einer Fernsteuerung (Fernseher), 56

2.1 Zahler als Zustandsmaschine, 20

2.20 Granularitat der parallelen Komposition mit gemeinsamen Variablen, 61

2.21 Anfangszustand bei gemeinsamen Variablen, 62

2.22 Stabilitat fur parallele Zustandsmaschinen, 63

2.23 Granularitat, 63

2.24 ZM, fur die Invariante I1 gilt, 64

2.25 Dekkers Algorithmus, 67

2.26 Semaphor, 69

2.27 Unvollstandigkeit des Beweiskalkuls, 71

2.27 Unvollstandigkeit des Beweiskalkuls (Fortsetzung), 73

2.28 Parallele Suche in einem Feld, 74

2.2 Sortieren durch eine Zustandsmaschine, 21

2.3 Ampel – Erreichbare Zustande, 24

2.4 Stabiles Pradikat fur Zahler als Zustandsmaschine, 27

2.5 Zustandsmaschine mit Invariante, 28

2.6 Instabile Invariante, 29

2.7 Keller als Zustandsmaschine mit markierten Ubergangen, 31

2.8 Zustandsraum als Belegung von Attributen, 34

2.9 Aufbrechen eines Programms (Fortsetzung), 40

2.9 Aufbrechen eines Programms in Zustandsubergangsdiagramm, 39

3.10 Spezifikation der Bedingungen an die Eingabe fur eine Warteschlange, 97

3.11 Spezifikation stromverarbeitender Funktionen, 98

3.12 Spezifikation stromverarbeitender Funktionen, 99

3.12 Spezifikation stromverarbeitender Funktionen (Fortsetzung), 101

3.13 Spezifikation des Systems Barrier, 103

3.14 Warteschlangen als Zustandsmaschine mit markierten Ubergangen, 107

3.1 Zwei ZM mit Ein/Ausgabe mit unterschiedlicher Zustandsraume aber mit gleichenSchnittstellenverhalten, 80

3.2 Einfache stromverarbeitende Funktionen (Datenflußfunktionen), 88

3.3 Warteschlange, 91

3.4 Rekursive Gleichungen fur Strome, 92

3.5 Erzeuger/Verbraucher mit Stromen, 93

18. Marz 2014 231


3.6 Das Sieb des Eratosthenes, 933.7 Nutzer und Programm als stromverarbeitende Funktionen, 943.8 Speicherzelle, 963.9 Der Strom der naturlichen Zahlen, 974.10 Parallele Komposition von zuweisungsorientierten Programmen, 1424.11 Erzeuger/Verbraucher mit pradikativer Spezifikation, 1424.12 Ubertragung eines Programms in eine pradikative Spezifikation, 1434.13 Addition und Ruckkopplung, 1444.14 Hamming-Sequenz durch Anweisungen, 1454.1 Alternating Bit Protokoll, 1144.2 Hammings Sequenz berechnet durch Datenflussgraph, 1194.3 Erzeuger-Verbraucher-Problem als Datenflussnetz, 1234.4 Fakultat als Datenflussnetz, 1254.5 Scheduler, 1304.6 Programm mit Kanal-Kommunikation, 1364.7 Zuweisungsorientierte Programme mit Ein- und Ausgabe, 1384.8 Programme zu den pradikativen Spezifikationen aus obigen Beispielen, 1394.9 Die Warteschlange als Programm mit Ein- und Ausgabe, 1405.1 Programmablauf mit Semaphoren, 1575.2 Sicherheits- und Lebendigkeitsbedingungen, 1585.3 Lift, 1635.4 Petri-Netze als Pradikate uber Ablaufen, 1655.5 Ablaufe in Petri-Netzen, 1665.6 Ablaufe einer stromverarbeitenden Funktion, 1685.7 Ableitung von Gleichungen aus Interaktionsdiagramm, 1695.8 Nichtdeterminismus und Unterspezifikation in MSCs, 1716.1 Nachrichtensynchrone Komposition von Automaten, 1746.2 Synchrone Komposition von Erzeuger/Verbraucher, 1746.3 Nachrichtensynchrone Komposition von Automaten, 1777.1 Zwei Systeme, die spur-, aber nicht bisimulationsaquivalent sind, 1917.2 Zwei Prozesse, die bereitschafts-, aber nicht bisimulationsaquivalent sind, 1948.1 Verfeinerung am Beispiel Datenspeicher, 2008.2 Parallele und Serielle Subtraktion, 2038.4 Abstraktion eines Automaten, 2108.5 Konstruktion abstrakter Zustandsmaschine, 2139.1 Der Zeitgeber, 2169.2 Nichtkausale Komponente, 218

232 18. Marz 2014

A. Anhang1

A.1. Komposition von

Assumption/Guarantee-Spezifikationen von Aktionen

In diesem Abschnitt betrachten wir Assumption/Guarantee-Spezifikationen von Kom-ponenten. In solchen Spezifikationen haben wir jede Komponente Ki durch AktionenFi und Ei spezifiziert, wobei Fi die Aktionen der Komponente selbst beschreibenund Ei die Aktionen der Umgebung. Jede Aktion beschreibt eine Relation auf demZustandsraum.

Wir konnen die Komponenten nur zusammensetzen, wenn sie ihren gegenseitigenAnforderungen entsprechen. Dies heißt dass fur jede Komponente Ki jede Aktiona ∈ Fi fur jede andere Komponente Kj (j 6= i) einer zulassigen Aktion b ∈ Eientspricht. Genauer gesagt muß gelten (fur alle i):

∀ a ∈ Fi, j, i 6= j : ∃ b ∈ Ej : b⇒ a

Mit anderen Worten, jede Komponentenaktion ergibt eine zulassige Umgebungsak-tion fur jede der anderen Komponenten. Wir erhalten eine neue Komponente, mitden Aktionen

∪ {Fi : 1 ≤ i ≤ n}

der Komponente und den Aktionen:

∪ {b1 ∧ . . . ∧ bn : b1 ∈ E1 ∧ . . . ∧ bn ∈ En}

Zusatzlich konnen noch Zugriffe auf bestimmte Variable eingeschrankt werden.

18. Marz 2014 233

B. Unterschiedliche Sichten: FOCUS undReo

Wie wir gesehen haben, gibt es mehrere Moglichkeiten dasselbe System darzustellen:Zustandssicht, Schnittstellensicht, Ablaufsicht, Struktur- und Verteilungssicht. Wirhaben in jedem Falle eine umfangreiche Wahl von Moglichkeiten zur Modellierungeines Systems. Die Entscheidung, welche Modellierung besonders geeignet ist, hangtimmer von der Natur des Systems ab und vom Anwendungszweck. Es kann passieren,dass wir in der Sicht A nie die gleiche Spezifikation wie in der Sicht B erhalten. Aberwie gehen wir systematisch vor, wenn wir zunachst eine abstrakte Spezifikationmochten und erst spater eine Verfeinerung davon?

Als Beispiel fur diese Situation betrachten wir das Alternating Bit Protocol (ABP,siehe Abschnitt 1.5) in zwei Sichten:

1. Reprasentation in FOCUS, einem allgemeinen Rahmen zur Spezifikation undFOCUS

Entwicklung verteilter Systeme (siehe [BS01b], [Spi98]).

2. Reprasentation in Reo durch kanalbasierte Koordinationsmodelle, abgestutztReo

auf Coinductive Calculus of Component Connectors (siehe [AR02] und[SAdBB03]).

Die Systeme in FOCUS werden als Netzwerke, bestehende aus so genannten Basi-sagenten, aufgebaut und im Allgemeinen durch Mengen von stromverarbeitendenFunktionen modelliert. In FOCUS beschreibt jede Spezifikation das Verhaltnis zwi-schen den Kommunikationsgeschichten (engl. communication histories) in Formvon Belegungen der externen Eingangs- und Ausgangskanalen. Die formale Bedeu-tung von Spezifikation ist genau diese Relation von Stromen. Man kann die FOCUSSpezifikationen in die Menge von Formeln strukturieren, so dass jede Formel eineEigenschaft des Systems beschreibt.

Reo ist als”glue language“ fur Konnektorskomposition eingefuhrt, die Basiskon-

nektoren sind Kanale. Reo verallgemeinert existierende Datenflussnetze.Der wichtigste Unterschied und Zusammenhang zwischen beiden Methoden wird

durch folgende Dualitat deutlich.

communications histories ↔ coalgebraic view

Abschnitte B.1 und B.2 stellen uns die kurze Einfuhrungen in die beiden Methodendar, im Abschnitt B.3 wird die FOCUS-Spezifikation fur Alternating Bit Protocol

234 18. Marz 2014

B.1. Einfuhrung in FOCUS

(vgl. [BS01b]) gegeben und im Abschnitt B.4 werden wir sehen, wie und warumwir in Reo keine Spezifikation entwickeln konnen, die der gleichen Abstraktionsebe-ne entspricht. In diesem Fall konnen wir in Reo nur eine konkretere Spezifikationschreiben, was nicht unbedingt ein Nachteil sein muss. Alles hangt davon ab, ob wirdiese Abstraktionsebene fur geeignet ansehen und was unsere nachsten Schrittensind.

Die FOCUS-Spezifikationen sind viel besser lesbar und uberschaubar, als die Spe-zifikationen in Reo, aber in Reo konnen wir die Strome auf Co-Algebra-Ebene be-trachten und Beweise bei Co-Induktion geben. Die FOCUS-Spezifikationen sindgrundsatzlich Formeln in der Pradikat-Logik und so es ist moglich, klassische lo-gische Kalkule zu benutzen, um Eigenschaften uber sie zu beweisen. Diese Beweisekonnen formell sogar durch automatische Proof Checkers ausgefuhrt werden.


Der nachfolgende Abschnitt gibt eine kurze Einfuhrung in FOCUS.

B.1.1. Allgemeine Eigenschaften

FOCUS ist eine Theorie und ein allgemeiner Rahmen zur Spezifikation und Entwick-lung verteilter Systeme. FOCUS bietet Spezifikationsformalismen und einen Verfei-nerungskalkul, die es erlauben, Systeme in schrittweisen Sichten zu beschreiben undzu implementieren.

Eine Entwicklung erfolgt in Top-Down-Vorgehensweise, wobei ein System ausge-hend von einer ersten (informellen) Beschreibung der gestellten Anforderungen ubermehrere Entwicklungsstufen hinweg bis zum gewunschten Detaillierungsgrad ent-wickelt wird. Zur Formalisierung verschiedener Aspekte des Systems werden unter-schiedliche Beschreibungstechniken eingesetzt. Die Semantik liefert eine mathemati-sche Beschreibung dafur, wie einzelne Systemteile zueinander in Beziehung stehen,wodurch das Verhalten des Systems bzw. der Systemteile festgelegt wird.

Durch die Verknupfung der Komponenten uber gerichtete Kanale wird die Struk-tur eines verteilten Systems festgelegt. Systeme werden ihrerseits als Komponentenmit Kanalverbindungen von bzw. zur Umgebung des Systems modelliert. Kompo-nenten konnen interagieren und unabhangig voneinander nebenlaufig arbeiten, wo-bei die Art der Vernetzung abhangig von den bestehenden Kanalverbindungen ist.Bestehen zwischen Komponenten keine Kanalverbindungen, so sind sie unabhangigvoneinander. Vor allem bei der Entwicklung komplexer Systeme mussen Komponen-ten separat entwickelt, zu einem Gesamtsystem komponiert oder in die Spezifikationeines bestehenden Systems integriert werden konnen. FOCUS unterstutzt diese Vor-gehensweise durch eine modulare Systementwicklung mit einer kompositionalen se-mantischen Basis. Die Komponenten interagieren durch den asynchronen Austauschvon Nachrichten uber die bestehenden Kanalverbindungen. Das beobachtbare Ver-

18. Marz 2014 235

Kapitel B. Unterschiedliche Sichten: FOCUS und Reo

halten eines Systems entspricht dem Nachrichtenfluss und wird festgelegt durch dieBeziehungen zwischen den Nachrichten, die eine Komponente empfangt, und denNachrichten, die sie verschickt. Die fur eine Komponente definierten Ein- und Aus-gabekanale zusammen mit den zugeordneten Nachrichten bilden die syntaktischeSchnittstelle einer Komponente.

B.1.2. Beschreibungstechniken

In FOCUS konnen wir ein System durch logische Formeln oder durch Diagrammeund Tabellen, die logische Formeln reprasentieren, darstellen. Die Techniken unter-scheiden sich in der Art, wie die Spezifizierungen strukturiert werden, und durch dielogischen Konstruktionen, die sie benutzen.

Eine Spezifikation kann elementar oder zusammengesetzt sein — zusamennge-setzte Spezifikationen werden hierarchisch aus den elementaren gebaut. ElementareSpezifikationen werden in untimed, timed und zeit-gleichzeitig gemaß ihres Niveausder Zeitabstraktion geteilt.

Spezifikationen aller drei Zeitrahmen kann man in Stile (engl. style) teilen:

� equational style: Die Komponente wird durch Gleichungen beschrieben, dieSpezifikationen gleichen Programmen, codiert in einer funktionalen Program-miersprache;

� assumption/guarantee style (A/G style): Die Komponente wird durch eine An-nahme und eine Garantie spezifiziert, d.h. nur wenn die Eingabe in Uber-einstimmung mit der Annahme ist, wird von der Komponente erwartet, dieGarantie zu erfullen;

� graphical style: Basiert auf Tabellen und Diagrammen, ist besser lesbar, dieserStil lasst sich schematisch in die Pradikatenlogik-Spezifikationen ubersetzen;

� relational style: Erlaubt Spezifikationen direkt als eine Beziehung zwischendem Eingang und Ausgangsstromen auszudrucken.

Jede Spezifikation in FOCUS beschreibt die Relation zwischen Kommunikations-geschichten (engl. communication histories) fur Belegungen der externen Ein- undAusgabekanale. Die formale Bedeutung einer Spezifikation ist genau diese externeEin-/Ausgabe Relation.

B.1.3. Strome und Operatoren auf Stromen

Das grundlegende Konzept in FOCUS sind Strome, die endliche und unendliche(vollstandige) Sequenzen von Nachrichten reprasentieren und die uber gerichteteKanale fließenden Kommunikationsgeschichten darstellen.

Es gibt die folgenden Arten von Stromen in FOCUS:

236 18. Marz 2014


� ungezeiteter Strom (engl. untimed stream): Eine Folge von Nachrichten, diein ihrer Ordnung der Ubertragung aufgeschrieben ist. Wenn ein ungezeite-ter Strom s die Kommunikationsgeschichte eines Kanals creprasentiert, dannkommt die j-k Nachricht gesandt entlang dem Kanal cals j-tes Element imStrom s vor.

� gezeiteter Strom (engl. timed stream): Eine Folge von Nachrichten und Zeit-ticks (engl. time ticks, dargestellt als

√). Die Nachrichten sind in ihrer Ordnung

der Ubertragung aufgeschrieben. Die Zeitticks modellieren eine diskrete Zeit.Die Nachrichten, die im Zeitintervall j+1 nach der Initiation der Ausfuhrungubertragen wurden, kommen zwischen Tick j und Tick j+1, der Tick j+1 zeigtdas Ende des Zeitintervalls j+1 an.

� zeitsynchroner Strom (engl. time-synchronous stream): Ein ungezeiteter Strommit einer besonderen gezeiteten Interpretation. Jede Nachricht in solchemStrom reprasentiert ein Zeitintervall. Folglich entspricht ein begrenzter gleich-zeitiger Strom s der Lange k einem gezeiteten Strom mit k Ticks, wobei dieNachricht j in s unmittelbar vor dem Tick j in s vorkommt.

In [BS01b] wird eine Menge von Operatoren auf Stromen definiert, hier besprechenwir nur einen kleinen Teil davon, den wir spater fur das ABP-Beispiel benutzenwerden.

# bezeichnet den Lange-Operator,Πi die i Projektion.⊗ Filter-Operator fur Stromen: A⊗ s entspricht dem Strom, den wir be-

kommen wenn wir alle Nachrichten aus s, die nicht von der Menge Asind, herausfiltern.

Filter-Operator fur den Tupeln von Stromen: (A × B) (s, p) ent-spricht dem Strom-Tupel (s′, p′), den wir bekommen wenn wir alleNachrichten aus (s, p) durch die Tupel-Menge A × B herausfiltern.

�.s der Strom s ohne aufeinander folgende Wiederholungen von Elemen-ten.

map(s, g)g angewandt auf jedes Element vom Strom s.Diese Operationen verwenden wir im Alternating Bit Protokol.

B.1.4. Verfeinerung

FOCUS ist hierarchisch konzipiert, wobei auch Netze (verteilte Systeme) durchstromverarbeitende Funktionen modelliert werden. Ein System kann in zwei Sichtenbeschreiben werden:

� Die Black-Box -Sicht zeigt ein System als Ein/Ausgabe-Einheit ohne Beruck-sichtigung ihres strukturellen Aufbaus.

18. Marz 2014 237


� Die Glass-Box -Sicht berucksichtigt zusatzlich die Vernetzung der Komponen-ten oder die Zustande und Zustandsubergange.

In der Glass-Box-Sicht wird das Verhalten des Systems durch das Zusammenspielder Komponenten bestimmt. Die Vernetzung der Komponenten ergibt sich aus denKanalverbindungen der Komponenten. Alle Kanale, die eine Komponente mit derUmgebung verbinden, liefern die Verbindung des Systems zur Umgebung. Auf die-ser Basis ist in FOCUS der Begriff des beobachtbaren Verhaltens gepragt: Es sindausschließlich die Nachrichten beobachtbar, die von der Umgebung gesendet oderempfangen werden.

Eine formale Top-Down-Systementwicklung wird in FOCUS mittels schrittweiserVerfeinerung durchgefuhrt. Das Verhalten von Komponenten wird durch Mengenvon Funktionen, die pradikativ spezifiziert werden, dargestellt. Auf dieser Basis kanndie Gultigkeit der Verfeinerungsschritte mittels logischer Implikation nachgewiesenwerden. Die drei wesentlichen Verfeinerungskonzepte umfassen die Verfeinerung von:

� Verhalten: zur Reduktion von Unterspezifikation;

� Schnittstelle: zur Weiterentwicklung und Konkretisierung einer Schnittstelle;

� Struktur : zur Entwicklung des strukturellen Aufbaus eines Systems.

FOCUS erlaubt damit die vollig formale Entwicklung hierarchischer verteilter Sys-teme.

B.2. Einfuhrung in Reo

Fur eine Einfuhrung in (Co)Algebren und (Co)Induktion, Bisimulation und dasKonzept großte Fixpunkte (greatest fixed point) siehe [JR97].

B.2.1. Allgemeine Eigenschaften

Der Name vom kanalbasierten Modell Reo kommt von dem griechischen Wort”ρεω“,

was bedeutet”Strom“. Reo stutzt sich auf das co-induktive Kalkul von Komponents-

konnektoren (Coinductive Calculus of Component Connectors), eingefuhrt von Far-had Arbab und Jan Rutten (CWI, Amsterdam). Die Basis-Konnektoren sind Kanale,jeder Kanal ist ein point-to-point Kommunikationsmedium mit zwei Enden, und miteinem liberaleren Begriff eines Kanals verallgemeinert Reo existierende Dataflow-Netze.

In Reo konnen wir auch die neuen Kanale definieren als auch komplexere Konnek-toren aus einfacheren (z.B. aus Basiskonnektoren) durch die Konnektorskompositionkonstruieren.

Ein Kanal in Reo sollte nicht beide Eingabe- und Ausgabe-Enden haben, er kannstattdessen z.B. zwei Eingabe- oder zwei Ausgabe-Enden haben.

238 18. Marz 2014


Die Konnektoren in Reo sind Relationen auf gezeiteten Datenstromen (engl. timeddata streams): Die Eingabe- und Ausgabe-Enden sind als Strome von abstraktenDatenelementen modelliert. Mit jedem solchen Datenstrom ist eine Sequenz vonnaturlichen oder nicht-negativen reellen Zahlen verbunden, die den Zeitstrom dar-stellt – diese Zahlen stehen fur entsprechende Zeitmomente in welchen zu denengehorende Datenelement Ein- oder Ausgabe war. Auf solche Weise konnen wir dieZeitbedingungen beschreiben und spezifizieren.

Das potenzielle Verhalten an den Enden des Konnektors wird als gezeitete Daten-strome modelliert, die Paare von einem Datenstrom und einem Zeitstrom sind.

Der mathematische Kern von Reo ist die Menge Aω von Stromen uber einer Men-ge A von Datenelementen oder Zeitmomenten. Diese Menge hat eine endliche Co-Algebra-Struktur (engl. final coalgebra structure), bestehend aus den Funktionenhead (

”initial value“) und tail (

”derivative of a stream“). Die endliche Co-Algebra

befriedigt Grundsatze der Co-Induktion, die sehr machtig sind und sowohl auf Daten-als auch auf gezeitete Strome angewandt werden konnen.

B.2.2. Strome und Co-Induktion

Die Definition von Stromen ist in Reo durch sogenannte behavioural differentialequations gegeben, die den Anfangswert (initial value) und die Ableitung des behavioural

differentialequations

co-induktiv

Stroms (derivative of the stream) definieren – man nennt solche Definitionen auchco-induktiv.

Sei A eine beliebige Menge und Aω die Menge von allen Stromen (in Reo – unend-liche Sequenzen) von A:

Aω = { α | α : {0,1,2,. . . } → A }

Die einzelnen Datenstrome werden als α = (α(0), α(1), α(2),. . . ) und die einzelneZeitstrome werden als a = (a(0), a(1), a(2), . . . ) bezeichnet.

Man nennt α(0) den Anfangswert (initial value) von den Strom α und

α′ = (α(1), α(2), . . . )

– die Ableitung des Stroms (derivative of the stream).Die

”hoher Ordnung“ Ableitung α(k) ist fur jedes k ≥ 0 wie folgend gegeben:

α(0) = α und α(k+1) = (α(k))′

∀n ≥ 0 : α′(n) = α(n+ 1) ∀n ≥ 0 : α(k)(n) = α(n+ k)

Sei D eine beliebige Datenmenge, wir definieren die Menge DS von Datenstromen als

DS = Dω

DS ist die Menge von allen Stromen α = (α(0), α(1), α(2), . . . ) uber D.Sei die Menge Nω von allen Stromen a = (a(0), a(1), a(2), . . . ) uber N. Wir defi-

nieren die Menge der Zeitstrome als

18. Marz 2014 239


TS = {a ∈ Nω|a < a′ }

Das bedeutet

∀a ∈ TS. ∀n ≥ 0. a(n) < a′(n) = a(n+ 1)

So besteht jeder Zeitstrom aus aufsteigenden Zeitmomenten:

a(0) < a(1) < a(2) < . . .

Wir verlangen, dass die Zeitstrome auch progressiv sind, um die Zeno-Paradoxe(unendlich viele Prozessschritte finden in einem beschrankten Zeitintervall statt) zuvermeiden:

∀ e ∈ TS. ∀ N ≥ 0. ∃ i ≥ 0 : e(i) > N

Die Menge TDS der gezeiteten Datenstromen definieren wir wie folgend:

TDS = DS × TS

Die Menge TDS enthalt die Paare 〈α, a〉:

α = (α(0), α(1), α(2), . . . ) und a = (a(0), a(1), a(2), . . . ).

Die co-induktiven Beweise fur Strome konnen wir durch das folgende Konzept an-geben. Eine Strom-Bisimulation ist eine Relation R ⊆ Aω × Aω, so dass

∀ α, β ∈ Aω α R β ⇒ α(0) = β(0) und α′ R β′

Die Vereinigung aller Bisimulationen ist auch eine Bisimulation, genannt Bisimila-rity.Bisimulation

Bisimilarity Wir benutzen Bisimulation um folgendes Co-induktion Beweisprinzip (engl. coin-duction proof principle) zu definieren:coinduction

proofprinciple ∀ α, β ∈ Aω. ∃ R (some bisimulation): α R β ⇒ α = β

Das bedeutet, wenn wir α = β zeigen wollen, brauchen wir nur eine Bisimulations-relation R ⊆ Aω × Aω mit α R β zu finden.

B.2.3. Konnektoren in Reo

Die Konnektoren in Reo sind Relationen auf gezeiteten Datenstromen (engl. timeddata streams). Jedes Argument einer solchen Relation kann als ein Eingabe- oderein Ausgabe-Ende des entsprechenden Konnektors gesehen werden.

Wir konnen auf diese Weise den Strom 〈α, a〉 als Behaviour-Szenario vom Kon-nektorende α darstellen.

In Reo definieren wir Konnektoren mittels großter Fixpunkte.Jeder Konnektor Con mit n Enden

240 18. Marz 2014


Con(〈α1, a1〉, . . . , 〈αn, an〉)

wird formal als großter Fixpunkt des monotonen Operators ΦCon(R) definiert, woR eine beliebige Relation R ⊆ TDS × · · ·× TDS auf n-Tupel von gezeiteten Daten-stromen ist, die der Definition von der Con-Relation entspricht. Nehmen wir alsBeispiel einen Misch-Konnektor merge [AR02]. Dieser Konnektor mischt zwei Ein-gabestrome α und β in einen Ausgangsstrom γ. Keines der Elemente vom Strom αund vom Strom β darf gleichzeitig kommen. Der Konnektor merge ist eine ternareRelation M mit zwei Eingabe- und einem Ausgabe-Strom. Diese Relation ist fur dieStrome 〈αa〉, 〈β, b〉 und 〈γ, c〉 uber einer beliebigen Menge D wie folgt definiert:

〈α, a〉

M

�

*

// 〈γ, c〉

〈β, b〉

≡ M(〈α, a〉, 〈β, b〉, 〈γ, c〉)

≡ a(0) 6= b(0) ∧( a(0) < b(0) ∧ γ(0) = α(0) ∧ c(0) = a(0) ∧ M(〈α′, a′〉, 〈β, b〉, 〈γ′, c′〉)∨b(0) < a(0) ∧ γ(0) = β(0) ∧ c(0) = b(0) ∧ M(〈α, a〉, 〈β′, b′〉, 〈γ′, c′〉) )

Die Relation M kann man formal als großten Fixpunkt des monotonen OperatorsΦM(R) fur beliebigen R ⊆ TDS × · · ·× TDS wie folgt definiert werden:

ΦM(R)(〈α, a〉, 〈β, b〉, 〈γ, c〉)⇔ a(0) 6= b(0) ∧

( a(0) < b(0) ∧ γ(0) = α(0) ∧ c(0) = a(0) ∧ R(〈α′, a′〉, 〈β, b〉, 〈γ′, c′〉)∨b(0) < a(0) ∧ γ(0) = β(0) ∧ c(0) = b(0) ∧ R(〈α, a〉, 〈β′, b′〉, 〈γ′, c′〉) )

Die M-Bisimulation ist eine Relation R mit R ⊆ ΦM(R). Darauf abgestutzt definierenwir das M-Co-Induktion Beweisprinzip:

wenn R(〈α, a〉, 〈β, b〉, 〈γ, c〉) fur eine beliebige M-Bisimulation R gilt,dann M(〈α, a〉, 〈β, b〉, 〈γ, c〉).

Konnektoren sind Relationen und deswegen konnen wir die Konnektorkompositionals Relationskomposition modellieren. Komposition bewirkt zwei Dinge gleichzeitig:Das Ausgangs-Ende des ersten Konnektors wird mit dem Eingangs-Ende des zwei-ten Konnektors identifiziert und das resultierende

”gemischte“ Ende wird außerdem

durch die existenzielle Quantifizierung verborgen.

18. Marz 2014 241


B.3. ABP-Reprasentation in FOCUS

Die Basis-Architektur von ABP-Protokoll in FOCUS ist in der Abb. B.1 gegeben.

MED

MED

SND RCV

as : Bit ar : Bit

ds : D × Bit dr : D × Bit

i : D

o : D

?

?

�

-

�

-

Abb. B.1.: Basis-Architektur von ABP-Protokoll in FOCUS

Die zwei Medien sind als parametrisierte Spezifikation gegeben: vgl. Abb. B.2.

Abb. B.2.: Medium-Spezifikation

Die Variable p funktioniert hier als ein Orakel, das entscheidet ob eine Nachrichtverloren geht. Wenn das Element j in diesem unendlichen Strom von Bits

”1“ ist,

dann kommt die Eingang-Nachricht j kommt diesen Medium durch, andernfalls gehtdiese Nachricht verloren – das zeigt formal das zweite Konjunkt. Das erste Konjunktstellt sicher, dass wenn man unendlich viele Nachrichten durch dieses Medium sen-det, dann werden auch unendlich viele Nachrichten erfolgreich weitergeleitet. Dasist die Fairness Anforderung an das Medium.

Die Spezifikation fur Sender ist in der Abb. B.3 gegeben.Die Konstruktion where definiert fds als einen Strom von gesendeten Nachrichten,fb als den zugehorigen Strom von gesendeten Bits und fas als den Strom vonangekommenen Bestatigungen. Man beachte, dass alle diese drei Strome so aus den

242 18. Marz 2014

B.3. ABP-Reprasentation in FOCUS

Abb. B.3.: Sender-Spezifikation

Eingangs- und Ausgangsstromen gebildet sind, in denen die aufeinander folgendeWiederholungen von Elementen geloscht sind.

Das erste Konjunkt fds v i verlangt fds einen Prafix-Strom von den Eingangs-strom i sein.

Das zweite Konjunkt ∝ .fb = fb verlangt, dass jedes neue Element von Daten-strom i mit dem Bit, das sich mit dem vorherigen Bit unterschiedet, zusammengesendet wird.

Das Konjunkt #fds = min{#i,#fds+ 1} stellt sicher, dass, wenn der Sender dieBestatigung bekommt, das nachste Element von Eingangsstrom gesendet wird.

Das letzte Konjunkt #i < #fas ⇒ #ds = ∞ beschreibt folgendes: Wenn einDatenelement nie vom Empfanger bestatigt wird, wird der Sender immer wiederdieses Element senden.

Beachte, man wird das Bit as als eine Bestatigung betrachten, wenn as das ersteBit ist oder wenn as nicht gleich zu vorherigem Bit ist – das bedeutet, das Bestati-gungsbit konnte sich vom gesendeten Bit unterscheiden.

Die Spezifikation von Empfanger (vgl. Abb. B.4) ist fast trivial: Das erste Kon-junkt ar = map(dr,Π2) stellt sicher, dass das komplementare Bit von jeder Ein-gangsnachricht durch ar weiter geleitet wird, und der zweite Konjunkt o = map(∝.dr,Π1) verlangt, dass der Ausgangsstrom o dem Strom dr gleich ist, wo alle aufein-ander folgende Wiederholungen von Elementen geloscht sind.

Die oben gegebene Spezifikationen zeigen wie man in FOCUS unterschiedliche Sortenvon Komponenten darstellen und zu einem Netz zusammenbinden kann. Beachte,dass relativ kleine Anderungen in der Spezifikation vollig unterschiedliche Eigen-schaften implizieren konnen.

18. Marz 2014 243


Abb. B.4.: Empfanger-Spezifikation

B.4. ABP-Reprasentation in Reo

ABP hat folgende Eigenschaft: Der Ausgangsstrom o sollte dem Eingangsstrom igleich sein. Wenn wir die gezeitete Version von ABP betrachten, genauer gesagt,die Version mit gezeiteten Datenstrome, bekommt diese Eigenschaft folgende Form:Fur den Eingangsstrom 〈α, a〉, der dem Strom i entspricht, und fur den Ausgangs-strom 〈β, b〉, der dem Strom o entspricht, muß folgendes gelten:

α = β ∧ a ≤ b

Man beachte, dass in dieser Spezifikation das Bestatigungsbit gleich dem gesen-deten Bit sein sollte. Wenn wir das ABP in FOCUS darstellen, konnen wir dieungezeitete Spezifikation benutzen, aber in Reo haben wir damit Probleme wegender co-algebraische Natur von Reo:

1) wenn das Medium das Bestatigungsbit verliert, wird der Sender nichts bekom-men und deswegen wird er ewig auf dieses Bit warten;

2) wenn das Medium die Nachricht mit dem komplementaren Bit verliert, wirdder Empfanger nichts bekommen und wird deswegen auch kein Bestatigungsbitsenden — auch in diesem Fall wird der Sender ewig auf das Bestatigungsbitwarten.

In FOCUS haben wir solche Probleme nicht, weil wir dort die ganzen Eingangs- undAusgangsgeschichten betrachten, in Reo aber haben wir nur beschrankten Zugriffzum Strom — jeder Zeitmoment konnen wir nur einen Stromelement beobachten,darum ist es unmoglich, die ABP-Spezifikation in Reo auf den gleichen Abstrakti-onsniveau wie in FOCUS darzustellen, fur den ABP-Fall konnen wir nur prazisereSpezifikation an geben.

In Reo mussen wir neue Zeitbeschrankungen fur die ABP-Spezifikation definieren:Der Sender sendet eine Nachricht und wartet eine bestimmte Zeit auf das Bestati-gungsbit. Wenn er wahrend dieser Zeit ein passendes Bestatigungsbit bekommt, sen-det er die neue Nachricht mit dem neuen komplementaren Bit zusammen. Wenn das

244 18. Marz 2014


Bestatigungsbit sich von dem erwarteten unterscheidet oder wenn der Sender keinBestatigungsbit wahrend der Wartezeit bekommt, sendet er die vorherige Nachrichtnochmals.

Um interne Zustande in Reo darzustellen, konnen wir entweder so genannteninternen Puffer modellieren, oder ein System von Relationen benutzen.

Fur die Modellierung des internen Puffers benutzen wir einen speziellen Konnektoraus einer Konnektorenfamilie (synchronen Kanal mit Startwert x).

Sei D eine beliebige Datenmenge und sei x ∈ D ein beliebiges Element aus dieserMenge, wir definieren diese Familie fur alle Strome 〈α, a〉 und 〈β, b〉 wie folgt:

〈α, a〉 x? ε // 〈β, b〉� ≡ β(0) = x ∧ b(0) = 0 ∧ β′ = α ? ε ∧ b′ = a

∗ stellt hier einen binaren Operator auf dem Eingangselement und einer Konstan-te ε ∈ D dar.

Der Konnektor enthalt zunachst den Datenelement x, so genannte start value, derzum ersten Ausgangselement β(0) = x in der Startzeit b(0) = 0 wird.

Fur die Modellierung des internen Timers benutzen wir folgenden Konnektor succ:

〈α, a〉 succ // 〈β, b〉� ≡ β(0) = x ∧ b(0) = 0 ∧ β = α + 1 ∧ β′ = a+ 1

Fur die einfache Ruckkopplung verwenden wir in Reo den Basiskonnektor synchro-nen Kanal (engl. synchronous channel):

〈α, a〉 // 〈β, b〉� ≡ β = α ∧ b = a

Damit sind alle Voraussetzungen geschaffen, um die Komponente in Einzelnen zuspezifizieren.

B.4.1. Sender

Sei Parameter t ∈ N die Dauer des Warteintervalls: Der Sender wartet auf dasBestatigungsbit t Zeitintervalls. Wenn er kein Bestatigungsbit wahrend dieser Zeitbekommt, schließt er, dass ein Medium entweder die Nachricht, oder das Bestati-gungsbit verloren hat.

Sender-Definition mit internem Puffer

Hier brauchen wir vier Extra-Enden vom Konnektor: λbi, λti, λbo und λto. Zweiandere Extra-Enden, τi und τo, werden wir benutzen um einen internen Timer zumodellieren.

Sei 〈α, a〉 der gezeitete Datenstrom uber der Eingansdatenmenge D, 〈γ, c〉, 〈λbi, lbi〉und 〈λbo, lbo〉 – die gezeiteten Datenstrome uber der Menge D × Bit, 〈µ,m〉 – uber derMenge Bit und seien 〈λti, lti〉, 〈λto, lto〉, 〈τi, ti〉 und 〈τo, to〉 die gezeiteten Datenstromeuber der Menge N. Wir definieren den Konnektor SND(t) wie folgt:

18. Marz 2014 245


〈α, a〉〈γ, c〉

〈µ,m〉

〈λbi, lbi〉 SND(t)

�

�

�

,

7

((

##

//

;;

〈λbo, lbo〉

〈λti, lti〉〈λto, lto〉

〈τi, ti〉〈τo, to〉

≡ SND(t ∈ N)(〈α, a〉, 〈µ,m〉, 〈λbi, lbi〉, 〈λti, lti〉, 〈τi, ti〉,〈γ, c〉, 〈λbo, lbo〉, 〈λto, lto〉, 〈τo, to〉)

≡ c ≥ a ∧ m ≥ a∧τi(0) = 0→ ( π1(γ(0)) = α(0) ∧ π2(γ(0)) = 1 ∧ c(0) = a(0) + 1 ∧

λto(0) = a(0) + t ∧ lto(0) = c(0) ∧τo(0) = c(0) ∧ to(0) = c(0) ∧ λbo(0) = γ(0) ∧ lbo(0) = c(0) ∧SND(t)(〈α′, a′〉, 〈µ,m〉, 〈λbi, lbi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉) )∧( m(0) ≤ τi(0) ∧ m(0) < λti(0) ∧ µ(0) = π2(λbi(0)) ∧π1(γ(0)) = α(0) ∧ π2(γ(0)) = ¬π2(λbi(0)) ∧c(0) = max{a(0),m(0)}+ 1 ∧ lbo(0) = c(0) ∧ lto(0) = c(0) ∧λto(0) = c(0) + t ∧ λbo(0) = γ(0) ∧ τo(0) = c(0) ∧ to(0) = c(0) ∧SND(t)(〈α′, a′〉, 〈µ′,m′〉, 〈λ′bi, l′bi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉)∨m(0) ≤ τi(0) ∧ m(0) < λti(0) ∧ µ(0) 6= π2(λbi(0)) ∧γ(0) = λbi(0) ∧ c(0) = m(0) + 1 ∧λto(0) = c(0) + t ∧ λbo(0) = λbi(0) ∧ lbo(0) = c(0) ∧ lto(0) = c(0) ∧τo(0) = c(0) ∧ to(0) = c(0) ∧SND(t)(〈α, a〉, 〈µ′,m′〉, 〈λ′bi, l′bi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉)∨m(0) > τi(0) ∧ τi(0) < λti(0) ∧τo(0) = τi(0) + 1 ∧ to(0) = ti(0) + 1 ∧SND(t)(〈α, a〉, 〈µ,m〉, 〈λbi, lbi〉, 〈λti, lti〉, 〈τ ′i , t′i〉,

〈γ, c〉, 〈λbo, lbo〉, 〈λto, lto〉, 〈τ ′o, t′o〉)∨τi(0) ≥ λti(0) ∧ γ(0) = λbi(0) ∧c(0) = τi(0) + 1 ∧ lbo(0) = c(0) ∧ lto(0) = c(0) ∧λto(0) = τi(0) + t ∧ λbo(0) = λbi(0) ∧ τo(0) = c(0) ∧ to(0) = c(0) ∧SND(t)(〈α, a〉, 〈µ,m〉, 〈λ′bi, l′bi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉) )

246 18. Marz 2014


Jetzt konnen wir die gesamte Sender-Komponente als ein System von Konnek-toren SND(t), succ-Konnektor, einem synchronen Kanal mit Startwert 0 und einemeinfachen synchronen Kanal darstellen:

〈α, a〉〈γ, c〉

〈µ,m〉 SND(t)

�

�

�+

33

zz $$_

// ∃〈λto, lto〉0 ��

∃〈λbi, lbi〉_

∃〈λti, lti〉

_

∃〈λbo, lbo〉

OO

∃〈τi, ti〉 � ∃〈τo, to〉succoo

≡ τo(0) = 0 ∧ τ ′o = τi + 1 ∧ to(0) = 0 ∧ t′o = ti + 1 ∧λbi = λbo ∧ lbi = lbo ∧λti(0) = 0 ∧ λ′ti = λto ∧ lti(0) = 0 ∧ l′ti = lto∧c ≥ a ∧ m ≥ a∧τi(0) = 0→ ( π1(γ(0)) = α(0) ∧ π2(γ(0)) = 1 ∧ c(0) = a(0) + 1 ∧

λto(0) = a(0) + t ∧ lto(0) = c(0) ∧τo(0) = c(0) ∧ to(0) = c(0) ∧ λbo(0) = γ(0) ∧ lbo(0) = c(0) ∧SND(t)(〈α′, a′〉, 〈µ,m〉, 〈λbi, lbi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉) )∧( m(0) ≤ τi(0) ∧ m(0) < λti(0) ∧ µ(0) = π2(λbi(0)) ∧π1(γ(0)) = α(0) ∧ π2(γ(0)) = ¬π2(λbi(0)) ∧c(0) = max{a(0),m(0)}+ 1 ∧ lbo(0) = c(0) ∧ lto(0) = c(0) ∧λto(0) = c(0) + t ∧ λbo(0) = γ(0) ∧ τo(0) = c(0) ∧ to(0) = c(0) ∧SND(t)(〈α′, a′〉, 〈µ′,m′〉, 〈λ′bi, l′bi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉)∨m(0) ≤ τi(0) ∧ m(0) < λti(0) ∧ µ(0) 6= π2(λbi(0)) ∧γ(0) = λbi(0) ∧ c(0) = m(0) + 1 ∧λto(0) = c(0) + t ∧ λbo(0) = λbi(0) ∧ lbo(0) = c(0) ∧ lto(0) = c(0) ∧τo(0) = c(0) ∧ to(0) = c(0) ∧SND(t)(〈α, a〉, 〈µ′,m′〉, 〈λ′bi, l′bi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉)∨m(0) > τi(0) ∧ τi(0) < λti(0) ∧τo(0) = τi(0) + 1 ∧ to(0) = ti(0) + 1 ∧SND(t)(〈α, a〉, 〈µ,m〉, 〈λbi, lbi〉, 〈λti, lti〉, 〈τ ′i , t′i〉,

〈γ, c〉, 〈λbo, lbo〉, 〈λto, lto〉, 〈τ ′o, t′o〉)∨τi(0) ≥ λti(0) ∧ γ(0) = λbi(0) ∧c(0) = τi(0) + 1 ∧ lbo(0) = c(0) ∧ lto(0) = c(0) ∧λto(0) = τi(0) + t ∧ λbo(0) = λbi(0) ∧ τo(0) = c(0) ∧ to(0) = c(0) ∧SND(t)(〈α, a〉, 〈µ,m〉, 〈λ′bi, l′bi〉, 〈λ′ti, l′ti〉, 〈τ ′i , t′i〉,

〈γ′, c′〉, 〈λ′bo, l′bo〉, 〈λ′to, l′to〉, 〈τ ′o, t′o〉) )

18. Marz 2014 247


Sender-Definition als ein System von Relationen

Wir brauchen hier drei Indizes x, y und z um den internen Timer zu modellierenund die Werte von der nachsten Time-Out und vorheriger Nachricht zu speichern,x ∈ N, y ∈ N und z ∈ D × Bit.

Sei 〈α, a〉 der gezeitete Datenstrom uber der Eingansdatenmenge D, 〈γ, c〉 – dergezeitete Datenstrom uber der Menge D × Bit und 〈µ,m〉 uber der Menge Bit.

Wir definieren den Konnektor SNDxyz(t) wie folgt:

〈α, a〉

〈µ,m〉 SNDxyz(t)

�

� // 〈γ, c〉

≡ SNDxyz(t ∈ N)(〈α, a〉, 〈µ,m〉, 〈γ, c〉)

≡ ∃x1, y1 ∈ N, ∃z1 ∈ D × Bit :y = 0 ∧ c(0) = a(0) + 1 ∧ π1(γ(0)) = α(0) ∧ π2(γ(0)) = 1 ∧x1 = c(0) ∧ y1 = c(0) + t ∧ z1 = γ(0) ∧SNDx1y1z1(t)(〈α′, a′〉, 〈µ,m〉, 〈γ′, c′〉)∨m(0) ≤ x ∧ m(0) ≤ y ∧ µ(0) = π2(z) ∧π1(γ(0)) = α(0) ∧ π2(γ(0)) = ¬µ(0) ∧ c(0) = max{a(0),m(0)}+ 1 ∧x1 = c(0) ∧ y1 = c(0) + t ∧ z1 = γ(0) ∧SNDx1y1z1(t)(〈α′, a′〉, 〈µ′,m′〉, 〈γ′, c′〉)∨m(0) ≤ x ∧ m(0) ≤ y ∧ µ(0) 6= π2(z) ∧ c(0) = m(0) + 1 ∧γ(0) = z ∧ x1 = c(0) ∧ y1 = c(0) + t ∧SNDx1y1z(t)(〈α, a〉, 〈µ′,m′〉, 〈γ′, c′〉)∨m(0) > x ∧ x < y ∧ x1 = x+ 1 ∧SNDx1yz(t)(〈α, a〉, 〈µ,m〉, 〈γ, c〉)∨x ≥ y ∧ c(0) = x+ 1 ∧ γ(0) = z ∧x1 = c(0) ∧ y1 = c(0) + t ∧SNDx1y1z(t)(〈α, a〉, 〈µ,m〉, 〈γ′, c′〉)

Wenn wir diese Komponente benutzen, beginnen wir immer mit der Relation

SND100(t)(〈α, a〉, 〈µ,m〉, 〈γ, c〉),

aber der dritte Index z konnte auch in diesem Schritt auch beliebig sein – zunachstbrauchen wir den Wert von diesem Index nicht.

248 18. Marz 2014


B.4.2. Medium

Sei 〈ω, e〉 und 〈ν, n〉 der gezeitete Datenstrom uber einer beliebigen Datenmenge, diein dem ABP-Fall entweder die Menge D × Bit (wenn das erste Medium eine Nachrichtvon Sender zum Empfanger ubertragt) oder die Menge D (wenn das zweite Mediumein Bestatigungsbit von Empfanger zum Sender ubertragt) sein kann. Wir definierenden Konnektor MED wie folgt:

〈ω, e〉 MED� // 〈ν, n〉

≡ MED(〈ω, e〉, 〈ν, n〉)

≡ e(0) ≤ n(0) ∧ ( ν(0) = ω(0) ∧ MED(〈ω′, e′〉, 〈ν ′, n′〉)∨MED(〈ω′, e′〉, 〈ν, n〉) )

Hier sind zwei Falle moglich:

� das Medium ubertragt die aktuelle Nachricht erfolgreich, der Konnektor MEDgibt das Eingangselement durch das Ende ν vorwarts und macht mit denStromen 〈ω′, e′〉 und 〈ν ′, n′〉 weiter,

� das Medium verliert die aktuelle Nachricht, der Konnektor gibt nichts aus undmacht mit den Stromen 〈ω′, e′〉 und 〈ν, n〉 weiter.

Wir haben die Fairness Anforderung an das Medium: Wenn man unendlich vieleNachrichten durch dieses Medium sendet, dann werden auch unendlich viele Nach-richten erfolgreich weitergeleitet.Das ist die Eigenschaft vom Konnektor MED, die wir leicht prufen konnen. Nehmenwir den Konnektor MED(〈ω, e〉, 〈ν, n〉). Nehmen wir auch an, dass fur alle k ≥ 0 dasMedium die Nachrichten ω(0) verliert, so haben wir

∀k ≥ 0. MED(〈ω(k), e(k)〉, 〈ν, n〉)

Von der MED-Definition haben wir

∀k ≥ 0. e(k) = e(k) ≤ n(0)

Wir haben auch die Annahme, dass die Reo-Strome progressiv sind:

∀e ∈ TS. ∀N ≥ 0. ∃ i ≥ 0. e(i) > N

und das ist ein Widerspruch wenn wir als N das erste Element vom Strom n nehmen.Folglich, ∃ k ≥ 0. ν(0) = ω(k) das Medium ubertragt die Nachricht erfolgreich.

Das beweist die Fairness-Eigenschaft vom MED-Konnektor.

18. Marz 2014 249


B.4.3. Empfanger

Empfanger-Definition mit internem Puffer

Sei 〈β, b〉 der gezeitete Datenstrom uber der Eingansdatenmenge D, 〈κ, k〉, 〈λi, li〉und 〈λo, lo〉 die gezeiteten Datenstrome uber der Menge Bit und 〈σ, d〉 uber der MengeD × Bit.

Wir definieren den Konnektor RCV wie folgt:

〈σ, d〉〈β, b〉

RCV

�

0

//

77

&&

〈κ, k〉

〈λi, li〉〈λo, lo〉

≡ RCV(〈σ, d〉, 〈λi, li〉, 〈β, b〉, 〈κ, k〉, 〈λo, lo〉)

≡ π2(σ(0)) 6= λi(0) ∧ λo(0) = ¬λi(0) ∧ β(0) = π1(σ(0)) ∧κ(0) = π2(σ(0)) ∧ b(0) = d(0) + 1 ∧ lo(0) = b(0) ∧ k(0) = b(0) ∧RCV(〈σ′, d′〉, 〈λ′i, l′i〉, 〈β′, b′〉, 〈κ′, k′〉, 〈λ′o, l′o〉)∨π2(σ(0)) = λi(0) ∧ λo(0) = λi(0) ∧ κ(0) = π2(σ(0)) ∧lo(0) = d(0) + 1 ∧ k(0) = d(0) + 1 ∧RCV(〈σ′, d′〉, 〈λ′i, l′i〉, 〈β, b〉, 〈κ′, k′〉, 〈λ′o, l′o〉)

Fur jedes Element vom Strom σ gibt es zwei Moglichkeiten:

� Das aktuelle Bit unterscheidet sich vom vorherigen Bit, der Konnektor gibt dasaktuelle Bit durch das Ende κ und λo aus. Der Nachrichtenteil des Elementsvom Strom σ gibt er durch das Ende β aus.

� Das aktuelle Bit ist gleich zum vorherigen Bit – das Medium hat das vorhe-rige Bestatigungsbit verloren, der Konnektor gibt das aktuelle Bit durch dasEnde κ und λo aus, um dieses Bestatigungsbit wieder zu senden.

Jetzt konnen wir die gesamte Sender-Komponente als ein System von Konnektoren

250 18. Marz 2014


RCV und einem synchronen Kanal mit Startwert 0 darstellen:

〈β, b〉

〈σ, d〉 RCV�

< ��

66

((∃〈λi, li〉 0

� ∃〈λo, lo〉oo 〈κ, k〉

≡ λi(0) = 0 ∧ λ′i = λo ∧ li(0) = 0 ∧ l′i = lo∧π2(σ(0)) 6= λi(0) ∧ λo(0) = ¬λi(0) ∧ β(0) = π1(σ(0)) ∧κ(0) = π2(σ(0)) ∧ b(0) = d(0) + 1 ∧ lo(0) = b(0) ∧ k(0) = b(0) ∧RCV(〈σ′, d′〉, 〈λ′i, l′i〉, 〈β′, b′〉, 〈κ′, k′〉, 〈λ′o, l′o〉)∨π2(σ(0)) = λi(0) ∧ λo(0) = λi(0) ∧ κ(0) = π2(σ(0)) ∧lo(0) = d(0) + 1 ∧ k(0) = d(0) + 1 ∧RCV(〈σ′, d′〉, 〈λ′i, l′i〉, 〈β, b〉, 〈κ′, k′〉, 〈λ′o, l′o〉)

Empfanger -Definition als ein System von Relationen

Wir brauchen hier einen Index x ∈ Bit, um dem Wert des gesendeten Bits zu spei-chern.

Sei 〈κ, k〉 der gezeitete Datenstrom uber der Datenmenge Bit, 〈σ, d〉 die gezeiteteDatenstrom uber der Menge D × Bit und 〈β, b〉 uber der Menge D.

Wir definieren den Konnektor RCVx(t) wie folgt:

〈β, b〉

〈σ, d〉 RCVx�

77

''〈κ, k〉

18. Marz 2014 251


≡ RCVx(〈σ, d〉, 〈β, b〉, 〈κ, k〉)

≡ ∃y ∈ Bit :π2(σ(0)) 6= x ∧ y = ¬x ∧ β(0) = π1(σ(0)) ∧κ(0) = π2(σ(0)) ∧ b(0) = d(0) + 1 ∧ k(0) = b(0) ∧RCVy(〈σ′, d′〉, 〈β′, b′〉, 〈κ′, k′〉)∨π2(σ(0)) = x ∧ κ(0) = π2(σ(0)) ∧ k(0) = d(0) + 1 ∧RCVx(〈σ′, d′〉, 〈β, b〉, 〈κ′, k′〉)

Wenn wir diese Komponente benutzen, beginnen wir immer mit der Relation RCV0(〈σ, d〉,〈β, b〉, 〈κ, k〉).

B.4.4. Komposition von Konnektoren

Die folgende Komposition von beschriebenen Konnektoren entspricht der Architek-tur des ABP-Protokolls (siehe Abb. B.5).

Diese Spezifikation zeigt, wie wir in Reo unterschiedliche Sorten von Kompo-nenten darstellen und in ein Netz zusammenbinden konnen. Wie auch in FOCUSkonnen relativ kleine Anderungen in der Reo-Spezifikation vollig unterschiedlicheEigenschaften implizieren.

MED~~ �

∃〈µ,m〉 ∃〈κ, k〉

〈α, a〉 SND

-

�

))

RCV

hh

//

-

〈β, b〉

∃〈γ, c〉 ∃〈σ, d〉

MED

>>�

Abb. B.5.: Komposition von Konnektoren

252 18. Marz 2014


18. Marz 2014 253

Date post:	11-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

· Gliederung 1. Verteilte, nebenl au ge, interaktive Systeme 1 1.1. Vorbemerkungen zu verteilten...

Documents