Â¨Ubungen zu â Modellierung verteilter Systemeâ

Technische Universität München SoSe 2013 

Institut für Informatik Lösungsblatt 4 

Prof. Dr. M. Broy, Dr. A. Malkis Ausgabe: 28. Mai 2013 

M. Gleirscher, V. Koutsoumpas, D. Marmsoler Besprechung: 6. Juni 2013 

Übungen zu ” 

Modellierung verteilter Systeme“ 

Aufgabe 1 Bank 

Gegeben ist die Spezifikation des Gesamtsystems Bank sowie dessen Verteilung auf zwei Teilsysteme 

Bargeldbezug und Kontoverwaltung (Abbildung 1): 

x: A U C 

y: B U D 

Bank 

(a) 

Bank 

a: A 

b: B 

Bargeldbezug 

i1: I1 

i2: I2 

c: C 

Kontoverwaltung 

(b) 

d: D 

var s : Array[n] Nat 

Abbildung 1: (a) Schnittstellensicht des Systems Bank, im Kontext dessen Nutzer. (b) Die Komponenten 

Bargeldbezug (Abstraktion eines Bankomaten bzw. eines Schalters) und Kontoverwaltung (Abstraktion 

eines Schalters bzw. eines Online-Portals) des Systems Bank. 

Gegeben sind ebenso folgende, informell beschriebene Eigenschaften: 

(1) Annahme über den Nutzer: ” 

Keine Überziehung: Falls zu keinem Zeitpunkt die Summe der erfolgreichen 

Bargeldabhebungen höher als die Summe der Einzahlungen ist, boniert das System dies 

mit leicht erhöhten Zinsen.“ Anmerkung: Um das Modell für die Aufgabe knapp zu halten, ist die 

Kontoverzinsung im Modell nicht zu berücksichtigen. 

(2) Ungezeitete Lebendigkeitseigenschaft: ” 

Unendlich oft sollen vom Nutzer Auszahlungen mindestens 

in Höhe aller Einzahlungen getätigt werden können.“ 

Führen Sie nun folgende Schritte durch:

(a) Entwerfen Sie je eine knapp gehaltene Moore-Maschine für die Teilsysteme Bargeldbezug (Auszahlung) 

und Kontoverwaltung (Einzahlung, Auszahlungsprüfung). 

(b) Führen Sie nun die zeitasynchrone, nachrichtensynchrone Komposition Bargeldbezug ‖ Kontoverwaltung 

durch und erstellen Sie eine Schnittstellenabstraktion der Ergebnismaschine. 

(c) Stellen Sie die beiden Zustandsmaschinen aus (a) als konstruktive Spezifikation von Stromfunktionen 

dar und leiten das Ergebnis der Komposition der beiden Stromfunktionen f 1 ⊗ f 2 her. 

(d) Die Ergebnisse aus (b) und (c) stellen das System Bank dar. Prüfen Sie nun anhand Ihrer Kompositionsergebnisse, 

ob die Eigenschaften (1) und (2) vom System Bank erfüllt werden. 

Lösung der Aufgabe 1 

Teilaufgabe a) Die Abbildungen 2 und 3 zeigen zwei Vorschläge für die gefragten Moore-Maschinen. Für 

die Teilaufgabe c) sei mit diesen Zustandsübergangsdiagrammen auch die beiden Strukturen (∆ b , Σ b0 ) für den 

Bargeldbezug und (∆ k , Σ k0 ) für die Kontoverwaltung gegeben. 

aabbruch; 

i1check(false,x,id) 

Bereit 

ahebeAb(x,id) 

Fernprüfung 

i2!prüfe(x,id) 

- 

Abhebung 

b!geld(x,id) 

i1check(true,x,id) 

Abbildung 2: Moore-Maschine für Bargeldbezug 

{s[1..n]:=0} 

Bereit 

czahleEin(x,id) 

{s[id]:=s[id]+x} 

Einzahlung 

d!ok 

czurück 

i2prüfe(x,id) 

- {if (s[id]>=x AND customerOk(id)) 

then s[id]:=s[id]-x} 

Prüfung 

i1!check(s[id]>=x AND customerOk(id),x,id) 


Abbildung 3: Moore-Maschine für Kontoverwaltung

Teilaufgabe b) Abbildung 4 zeigt im ersten Schritt die asynchron in Zeit und Nachrichten “roh” komponierte 

Moore-Maschine für Bank. Kurzbezeichnungen für Ein- und Ausgabeaktionen: 

QT ≡ “aabbruch; i1check(false,x,id)”, 

OK ≡ “i1check(true,x,id)”, 

ZE ≡ “czahleEin(x,id) {s[id]:=s[id]+x}”, 

V R ≡ “i1!check(s[id]>=x AND customerOk(id),x,id)”, 

UP ≡ “- {if (s[id]>=x AND customerOk(id)) then s[id]:=s[id]-x}” 

Es gibt 17 Klassen von Zuständen (sog. Kontrollzustände), die wir im Zustandsübergangsdiagramm (ZÜD) 

durch 17 Knoten unterscheiden. Das Kreuzprodukt der Kontrollzustände und der Auswahl je einer Ausgabeaktion 

ergibt 3∗3∗2 = 18, lediglich die Kontrollzustände “Bereit/Bereit” sind schon vereinigt, da es dort in beiden 

Maschinen keine Ausgabeaktionen gibt. Die Funktion customerOk(id) : N → Bool prüft, ob der Nutzer mit 

dem Identifikator id ein Kunde der Bank ist. 

OK 


Abhebung 

Prüfung 

VR 

UP 

Abhebung 

Bereit 

b!geld(x,id) 


OK 


ZE 

ZE 

- 


ZE 

Fernprüfung 

Bereit 

Abhebung 

Einzahlung 

d!ok 

- 

- 

Bereit 

Prüfung 

Fernprüfung 

Einzahlung 

d!ok 


- 

UP 

QT 

UP 

QT 

{s[1..n] :=0} 



UP 


OK 

OK 


Fernprüfung 

Prüfung 

VR 

QT 

ZE 

Bereit 

Bereit 

Abhebung 

Einzahlung 

b!geld(x,id) 


- 


ahebeAb(x,id) 


- 

Bereit 

Einzahlung 

Fernprüfung 

Bereit 



QT 

ZE 

UP 

QT 

OK 

ahebeAb(x,id) 


Fernprüfung 

Einzahlung 


Bereit 

Einzahlung 

d!ok 


ahebeAb(x,id) 

Abhebung 

Bereit 

UP 


Abhebung 

Prüfung 

b!geld(x,id) 

ahebeAb(x,id) 

OK 

QT 

Fernprüfung 

Prüfung 


ahebeAb(x,id) 


VR 

Bereit 

Prüfung 



Abbildung 4: Asynchron in Zeit und Nachrichten “roh” komponierte Moore-Maschine für Bank. 

Abbildung 5 zeigt im zweiten Schritt die nachrichtensynchrone Reduktion der Moore-Maschine für Bank, 

wobei keine Nachrichtensynchronität mit dem Benutzer berücksichtigt ist. D.h. ohne Eingabepuffer verliert

Bank z.B. ungünstig kommende “aabbruch” Nachrichten. Entsprechende Transitionen und Zustände sind 

entfernt worden. Dies betrifft auch Zusammenhangskomponenten im ZÜD, die (von “Bereit/Bereit” aus) nicht 

mehr erreichbar sind. Man beachte, dass uns diese Transformation eine Verklemmungssituation herbeiführt. 

Die nötige zusätzliche “i2prüfe”-Transition und deren Konsequenzen im Zustand “Prüfung” betrachten wir im 

Rahmen der Aufgabe nicht mehr. Schon hier könnte man bei allen nachrichtensynchronen Übergängen der beiden 

Maschinen die Kontrollzustände (hier “Fernprüfung/Bereit” und “Fernprüfung/Einzahlung”) eliminieren, dies 

erfolgt aber erst im nächsten Schritt. 

Fernprüfung 

Prüfung 

{s[1..n] :=0} 

Bereit 

Einzahlung 

ahebeAb(x,id) 


Bereit 

Prüfung 

UP 

Bereit 

Bereit 



Bereit 

Einzahlung 

QT 

Fernprüfung 

Bereit 



ahebeAb(x,id) 

- 

ZE 

d!ok 

ahebeAb(x,id) 

ahebeAb(x,id) 

- 

- 

Fernprüfung 

Prüfung 


Fernprüfung 

Einzahlung 

VR 


OK 

Abhebung 

Bereit 

ZE 

Abhebung 

Einzahlung 

Abhebung 

Prüfung 

UP 

d!ok 

b!geld(x,id) 




Potentielle Verklemmung 

Abbildung 5: Nachrichtensynchrone Reduktion der Moore-Maschine für Bank. 

Abbildung 6 zeigt im dritten Schritt die Schnittstellenabstraktion der Moore-Maschine für Bank. Alle Kommunikation 

über i1 und i2 sowie interne Zuweisungen/Referenzen auf s werden eliminiert (leere Transitionen 

werden eliminiert; Zustände, welche keine nutzersichtbaren Ausgaben produzieren bzw. keine Nutzereingaben 

entgegen nehmen wurden verschmolzen: Unsichtbare Transitionen bzw. Leerschritte (nicht die mit der leeren 

Nachricht “–”) werden zu Schleifen (bei Hin- und Rücktransitionen) oder verschwinden (bei Transitionen in 

eine Richtung). Man beachte die nichtdeterministische Ausgabe “−; y!geld(x, id)” (der Strichpunkt ; vereinigt 

hier zwei Transitionen oder Ausgaben zwecks kompakterer Notation) im grünen Zustand sowie den nichtdeterministischen 

Übergang mit “−” von dort aus. Damit erhalten wir eine Spezifikation, die nach wie vor eine 

Verklemmung aber zusätzlich noch mehr Verhalten zulässt als die ursprüngliche Komposition. Teilaufgabe d) 

zeigt auf Basis von Strömen, wie eine solche Spezifikation wieder sinnvoll eingeschränkt werden kann, in dem 

zusätzlich geforderte Verhaltenseigenschaften potentielle Spezifikationsänderungen nach sich ziehen. Alternativ 

zur Teilaufgabe c) ist mit diesem Zustandsübergangsdiagramm auch die Struktur (∆ bank , Σ bank0 ) für die Bank 

gegeben.

Fernprüfung 

Prüfung 

Bereit 

Bereit 

xzahleEin(x,id) 

xzurück 



Potentielle Verklemmung 

Bereit 

Einzahlung 

- 

y!ok 

xhebeAb(x,id) 

xhebeAb(x,id) 

Bereit 

Prüfung 

UP 

xabbruch; - 

xhebeAb(x,id) 

"Fernprüfung|Abhebung" 

"Bereit|Prüfung|Einzahlung" 

-; 

y!geld(x,id) 


Abhebung 

Bereit 

UP 

xzahleEin(x,id) 

Abhebung 

Einzahlung 

y!ok 

xhebeAb(x,id) 

- 

Bereit 

Einzahlung 


Abbildung 6: Schnittstellenabstraktion der Moore-Maschine für Bank. 

Teilaufgabe c) Im Folgenden werden wir die beiden Komponenten Bargeldbezug und Kontoverwaltung als 

stromverarbeitende Funktionen darstellen. Wir beginnen damit die Menge der Kanäle für Bargeldbezug und 

Kontoverwaltung wie folgt zu definieren: 

• Bargeldbezug: I b = {a, i1}, O b = {b, i2}. 

• Kontoverwaltung: I k = {c, i2}, O k = {d, i1}. 

Nun können wir die syntaktischen Schnittstellen der beiden Teilsysteme wie folgt definieren: 

• Bargeldbezug: (I b ◮ O b ). 

• Kontoverwaltung: (I k ◮ O k ). 

Schließlich können wir die semantischen Schnittstellen der Systeme als Funktionen über die zugehörigen syntaktischen 

Schnittstellen definieren. Beachten sie dass wir im Folgenden eine Historie als Sequenz von Belegungen 

behandeln. Eine Historie −→ I bzw. −→ O einer Komponente mit Schnittstelle (I ◮ O) ist somit eine Sequenz von 

funktionen der Art 

I → M bzw. O → M. 

Im Folgenden werden wir zwei verschiedene Techniken zur rekursiven Definition von stromverarbeitenden Funktionen 

einsetzen:

• Direkte Definition über Ein-/Ausgabe: Die Funktion wird rekursiv über das Muster der Eingabebelegungen 

definiert. 

• Definition unter Verwendung lokaler Zustände: Die Funktion wird rekursiv über das Muster von Eingabebelegungen 

in Abhängigkeit einer weiteren Hilfsfunktion definiert. Die Hilfsfunktion repräsentiert eine 

Art Datenzustand und wird verwendet um den Kontostand der Kunden zu kapseln. 

Im Folgenden werden wir die stromverarbeitende Funktion für die Komponente Bargeldbezug als Ein-/Ausgabe 

Funktion definieren. Das Schnittstellenverhalten f b : −→ I b → −→ O b ist dabei wie folgt definiert, wobei das Symbol 

ɛ für die leere Übertragung steht und i, i ′ , i ′′ sowie o, o ′ , o ′′ Kanalbelegungen darstellen und rest ∈ −→ I b und 

x, id ∈ N: 

f b (〈〉) = 〈〉 (1) 

i(a) = hebeab(x, id) ∧ i(i1) = ɛ 

⇒ f b (〈i〉) = 〈o〉 (2) 

∧o(i2) = prüfe(x, id) ∧ o(b) = ɛ 

i(a) = hebeab(x, id) ∧ i ′ (i1) = check(true, x, id) ∧ i(i1) = i ′ (a) = ɛ 

⇒ f b (〈i〉) = 〈o〉 (3) 

∧o(i2) = prüfe(x, id) ∧ o ′ (b) = geld(x, id) ∧ o(b) = o ′ (i2) = ɛ 

i(a) = hebeab(x, id) ∧ (i ′ (i1) = check(false, x, id) ∧ i ′ (a) = ɛ ∨ i ′ (a) = abbruch ∧ i ′ (i1) = ɛ) ∧ i(i1) = ɛ 

⇒ f b (〈i〉ˆ〈i ′ 〉ˆ〈rest〉) = 〈o〉ˆ〈o ′ 〉ˆf b (〈rest〉) (4) 

∧o(i2) = prüfe(x, id) ∧ o(b) = o ′ (b) = o ′ (i2) = ɛ 

i(a) = hebeab(x, id) ∧ i ′ (i1) = check(true, x, id) ∧ i(i1) = i ′ (a) = i ′′ (a) = i ′′ (i1) = ɛ 

⇒ f b (〈i〉ˆ〈i ′ 〉ˆ〈i ′′ 〉ˆ〈rest〉) = 〈o〉ˆ〈o ′ 〉ˆ〈o ′′ 〉ˆf b (〈rest〉) (5) 

∧o(i2) = prüfe(x, id) ∧ o ′ (b) = geld(x, id) ∧ o(b) = o ′ (i2) = o ′′ (b) = o ′′ (i2) = ɛ 

Beachten Sie dass f b Präfix-monoton ist, also i 1 ⊑ i 2 ⇒ f b (i 1 ) ⊑ f b (i 2 ) gilt. Dies ist notwendig um sicherzustellen 

dass die Funktion auch realisierbar ist. Des weiteren ist zu beachten dass die Funktion partiell ist, dass 

also nicht jede Eingabehistorie eine Ausgabehistorie liefert. 

Um sicherzustellen dass die so definierte Funktion in der Tat eine Abstraktion der Zustandsmaschinen aus 

Teilaufgabe a ist, also f b = Abs((∆ b , Σ b0 )) gilt, muss die Abstraktion folgender Bedingung (siehe Foliensatz 

6, Folie 25) genügen, wobei Abläufe eine Funktion ist welche alle möglichen Abläufe einer Zustandsmaschine 

liefert: 

Vermutung. f b (i) = o ⇔ ∃σ n ∈ Abläufe((∆ b , Σ b0 )). σ 0 ∈ Σ b0 ∧ ∀n ∈ N.(σ n+1 , o(n + 1)) = ∆(σ n , i(n + 1)) 

Ohne Beweis. 

Analog dazu können wir die stromverarbeitende Funktion der Komponente Kontoverwaltung definieren. Hier 

werden wir die stromverarbeitende Funktion aber als Funktion mit lokalen Zuständen definieren. Der Zustand 

ist in diesem Fall das Guthaben eines jeden Kunden. Wir können das Schnittstellenverhalten der Komponente

f k : −→ I k → −→ O k dann einfach als f k = f h [nil] definieren, wobei f h : s → ( −→ I k → −→ O k ) eine Funktion ist, die das 

Schnittellenverhalten in Abhängigkeit eines Zustandes s : N → N festlegt, wobei s(id) den aktuellen Betrag 

eines Kunden mit Identifikation id liefert und nil : N → N die Funktion ist welche den Betrag 0 für jeden 

Kunden zurückgibt, also nil(id) = 0 für alle Kunden id. Die Funktion f h wird wie folgt definiert, wobei das 

Symbol ɛ für die leere Übertragung steht und i, i ′ , i ′′ sowie o, o ′ , o ′′ Kanalbelegungen darstellen und rest ∈ −→ I k : 

f h [s](〈〉) = 〈〉 (1) 

i(c) = zahleEin(x, id) ∧ i(i2) = ɛ 

⇒ f h [s](〈i〉) = o (2) 

∧o(d) = ok ∧ o(i1) = ɛ 

i(c) = zahleEin(x, id) ∧ i ′ (i2) = prüfe(x, id) ∧ i(i2) = i ′ (c) = ɛ 

⇒ f h [s](〈i〉ˆ〈i ′ 〉) = 〈o〉ˆ〈o ′ 〉 (3) 

∧o(d) = ok ∧ o ′ (i1) = check(s(id) > x ∧ customerOk(id), x, id) ∧ o(i1) = o ′ (d) = ɛ 

i(i2) = prüfe(x, id) ∧ i(d) = ɛ 

⇒ f h [s](〈i〉) = 〈o〉 (4) 

∧o(i1) = check(s(id) > x ∧ customerOk(id), x, id) ∧ o(d) = ɛ 

i(c) = zahleEin(x, id) ∧ i ′ (c) = zurück ∧ i(i2) = i ′ (i2) = ɛ 

⇒ f h [s](〈i〉ˆ〈i ′ 〉ˆ〈rest〉) = 〈o〉ˆ〈o ′ 〉ˆf k [s ′ ](〈rest〉) (5) 

{ 

∧o(d) = ok ∧ o(i1) = o ′ (d) = o ′ (i1) = ɛ ∧ s ′ s(z) wenn z ≠ id 

(z) = 

s(z) + x sonst 

i(c) = zahleEin(x, id) ∧ i ′ (i2) = prüfe(x, id) ∧ i(i2) = i ′ (c) = i ′′ (c) = i ′′ (i2) = ɛ ∧ s(id) > x ∧ customerOk(id) 

⇒ f h [s](〈i〉ˆ〈i ′ 〉ˆ〈i ′′ 〉ˆ〈rest〉) = 〈o〉ˆ〈o ′ 〉ˆ〈o ′′ 〉ˆf k [s ′ ](〈rest〉) (6) 

∧o(d) = ok ∧ o ′ (i1) = check(s(id) > x ∧ customerOk(id), x, id) ∧ o(i1) = o ′ (d) = o ′′ (d) = o ′′ (i1) = ɛ 

{ 

∧s ′ s(z) wenn z ≠ id ∨ s(id) ≤ x ∨ ¬customerOk(id) 

(z) = 

s(z) − x sonst 

Beachten Sie dass auch f k Präfix-monoton ist, also i 1 ⊑ i 2 ⇒ f k (i 1 ) ⊑ f k (i 2 ) gilt. Dies ist notwendig um 

sicherzustellen dass die Funktion auch realisierbar ist. Des weiteren ist zu beachten dass die Funktion partiell 

ist, dass also nicht jede Eingabehistorie eine Ausgabehistorie liefert. 

Um sicherzustellen dass die so definierte Funktion in der Tat eine Abstraktion der Zustandsmaschine aus 

Teilaufgabe a ist, also f k = Abs((∆ k , Σ k0 )) gilt, muss die Abstraktion wie schon zuvor folgender Bedingung 

genügen: 

Vermutung. f k (i) = o ⇔ ∃σ n ∈ Abläufe((∆ b , Σ k0 )). σ 0 ∈ Σ k0 ∧ ∀n ∈ N.(σ n+1 , o(n + 1)) = ∆(σ n , i(n + 1)) 

Ohne Beweis.

Parallele Komposition der Funktionen: Es gibt nun verschiedene Möglichkeiten die Komposition 

der beiden stromverarbeitenden Funktionen zu definieren. Da wir die Komposition in Teilaufgabe b schon 

anhand der Zustandsmaschinen vorgenommen haben und wir wissen dass die Abstraktion durch Komposition 

distribuiert, also Abs((∆1, Σ1) ‖ (∆2, Σ2)) = Abs(∆1, Σ1) ⊗ Abs(∆2, Σ2) gilt (siehe Foliensatz 7, Folie 27), 

könnten wir einfach eine Funktion für die Zustandsmaschine aus Abbildung 6 angeben, genau so wie wir das 

schon zuvor für Bargeldbezug und Kontoverwaltung gemacht haben. 

Wir werden im Folgenden jedoch eine alternative Definition anbieten. Wir werden die Komposition der 

beiden Funktionen als kleinsten Fixpunkt des folgenden Gleichungssystems definieren. Zunächst definieren wir 

aber die Ein-/Ausgabekanäle des zusammengesetzten Systems: I = (I b ∪ I k ) \ (O b ∪ O k ) = {a, i1} ∪ {c, i2} \ 

{b, i2} ∪ {d, i1} = {a, c} und O = (O b ∪ O k ) \ (I b ∪ I k ) = {b, i2} ∪ {d, i1} \ {a, i1} ∪ {c, i2} = {b, d}. Die 

Menge L = (I b ∪ I k ) ∩ (O b ∪ O k ) = ({a, i1} ∪ {c, i2}) ∩ ({b, i2} ∪ {d, i1}) = {i1, i2} sind dabei die Menge 

der internen Kanäle des Systems. Die Schnittstelle des zusammengesetzten Systems ist somit durch (I ◮ O) 

gegeben. Wir definieren nun eine Funktion f bank : −→ I → −→ O wobei f bank = f b ⊗ f k als kleinster Fixpunkt des 

folgenden Gleichungssystems definiert ist. Im Folgenden bezeichnet z | C ′ die Restriktion der Belegung z auf 

die Teilmenge C ′ ⊆ C. 

• f bank (z) | O b = f b (z | I b ) 

• f bank (z) | O k = f k (z | I k ) 

Da f b und f k Präfix-monoton sind und die Menge der stromverarbeitenden Funktionen zusammen mit der 

Präfix-ordnung eine ketten vollständige Ordnung bilden, kann man nun zeigen dass der kleinste Fixpunkt 

dieses Systems auch wirklich existiert und eindeutig ist (Satz von Kleene). Dadurch ist also die Funktion f bank 

wohldefiniert und wir können sie als Definition verwenden. 

Die Komposition sollte übrigens wiederum folgender Eigenschaft genügen: 

Vermutung. f bank (i) = o ⇔ ∃σ n ∈ Abläufe((∆ bank , Σ bank0 )).σ 0 ∈ Σ bank0 ∧ ∀n ∈ N.(σ n+1 , o(n + 1)) = 

∆(σ n , i(n + 1)) 

Ohne Beweis. 

Teilaufgabe d) 

Für beide Eigenschaften definieren wir nun eine Hilfsfunktion 

fct sum = (s : Stream) N : returnFirstPar(first(s)) + sum(rest(s)) 

sum(〈〉) = 0 

wobei returnFirstPar(String) den ersten Parameterwert eines Terms zurück gibt. So kann die Eigenschaft (1) 

wie folgt spezifiziert werden: 

Selbiges für die Eigenschaft (2): 

sum({zahleEin( , id)} ⊗ x, id) ≥ sum({geld( , id)} ⊗ y, id) (7) 

sum({zahleEin( , id)} ⊗ x, id) ≤ sum({geld( , id)} ⊗ y, id) (8) 

M ⊗ x filtert aus dem Strom x alle Nachrichten heraus, die nicht in der Nachrichtenmenge M sind. 

TODO: Prüfung anhand von Abbildung 6. 

Aufgabe 2 Stromverarbeitende Funktionen 

• Syntaktische und semantische Korrektheit von Strömen 

Sei M = {⊥, 0, 1, 2, . . .}. Seien x, y ∈ M \ {⊥} Elemente aus einem Strom und seien s, t ∈ M ω 

Ströme über M mit der Trägermenge M ω = (M \ {⊥}) ∗ ∪ (M \ {⊥}) ∞ und s ≠ 〈〉. Geben Sie für 

die folgenden Terme an, ob diese syntaktisch und ggf. semantisch korrekt, also wahr oder falsch, 

sind:

(a) first(〈1, 2, 3〉) = 1 

(b) rest(〈1, 2, ⊥, 3, 4〉) = rest(〈1, 2〉) 

(c) sˆt = tˆs 

(d) first(sˆt) = first(s) 

(e) (xˆs)ˆt = xˆ(sˆt) 

(f) first(rest(first(〈1, 2, 3〉))) = ⊥ 

(g) rest(rest(rest(x&(y&s)))) = rest(s) 

• Stromverarbeitende Funktionen 

(a) Spezifizieren Sie eine Komponente, die zwei sortierte (monotone) Eingabeströme natürlicher 

Zahlen vereint und als einen sortierten Ausgabestrom wieder ausgibt. Geben Sie dazu die 

Signatur und die Spezifikation dieser Komponente an. 

(b) Modellieren Sie nun eine realisierende Funktion Ihrer Spezifikation. 

(c) Modellieren Sie eine Komponente mit zwei Eingabekanälen und einem Ausgabenkanal, jeweils 

vom Typ Nat, die wiederholt die ersten zwei Zahlen von den Eingabeströmen multipliziert 

und das Ergebnis auf dem Ausgabestrom ausgibt. 

• Axiomatische Spezifikation stromverarbeitender Funktionen 

In dieser Aufgabe wollen wir stromverarbeitende Funktionen durch Schnittstellenzusicherungen 

spezifizieren. Eine Warteschlange soll Daten vom Typ Data speichern und bei Eingabe des Zeichens 

∇ einen gespeicherten Wert nach dem FIFO Prinzip zurückgeben. Beispielsweise soll bei einem 

Input 

〈1, 2, ∇, 4, ∇〉 

der Output 

berechnet werden. 

〈 , , 1, , 2〉 

Modellieren Sie die Komponente indem Sie Schnittstellenzusicherungen angeben.


Syntaktische und semantische Korrektheit von Strömen 

Diskussion: Syntax vs. Semantik 

(a) first(〈1, 2, 3〉) = 1 

Richtig 

(b) rest(〈1, 2, ⊥, 3, 4〉) = rest(〈1, 2〉) 

Richtig, da 1&2& ⊥ &3&4 = 〈1, 2〉 

⊥ schneidet den Strom ab. Man sieht das, wenn man den Strom auf Normalform (1&2& . . .) 

bringt, dann kann man Axiome der Vorlesung anwenden. 

(c) sˆt = tˆs 

Syntaktisch richtig, aber semantisch falsch. Konkatenation ist nicht kommutativ. 

(d) first(sˆt) = first(s) 

Richtig, da s nicht leer ist. 

(e) (xˆs)ˆt = xˆ(sˆt) 

Syntaktisch falsch, da x eine Nachricht ist und ˆ ist daher nicht anwendbar. 

Richtig wären: (x & s)ˆt = x & (sˆt) und (〈x〉ˆs)ˆt = 〈x〉ˆ(sˆt) 

(f) first(rest(first(〈1, 2, 3〉))) = ⊥ 

Syntaktisch falsch, da first eine Nachricht zurück gibt. rest ist dafür nicht definiert. Zusätzliche 

Diskussion ob es überhaupt Fälle geben kann, in denen es sinnvoll ist ⊥ in Axiomen 

zu verwenden. Ja, z.B. in rest(〈〉) =⊥. 

(g) rest(rest(rest(x&(y&s)))) = rest(s) 

Richtig 

Stromverarbeitende Funktionen 

• Aufgabe a) 

fct merge : Stream Nat, Stream Nat → Stream Nat 

sorted(a) ∧ sorted(b) ∧ c = merge(a, b) 

=⇒ sorted(c) 

∧ ∀i, j : a i ≤ b j ⇒ ∃k : c k = a i 

∧ ∀i, j : a i ≥ b j ⇒ ∃k : c k = b j 

∧ ∀k : ∃i: c k = a i ∨ c k = b i 

sorted(〈〉) 

sorted(〈x〉) 

sorted(x&y&s) ⇐⇒ (x ≤ y ∧ sorted(y&s))

• Aufgabe b) 

fct merge = (a: Stream Nat, b: Stream Nat)Stream Nat: 

if a = 〈〉 then b 

else if b = 〈〉 then a 

else if first(a) ≤ first(b) then first(a)ˆmerge(rest(a), b) 

else first(b)ˆmerge(a, rest(b)) 

• Aufgabe c) 

fct smult(s1, s2 : StreamNat)StreamNat : 

(first(s1) ∗ first(s2))&smult(rest(s1), rest(s2)) 

Axiomatische Spezifikation stromverarbeitender Funktionen 

Zunächst können wir uns überlegen, wie eine stromverarbeitende Funktion für die Warteschlange aussehen 

könnte. Seien nun I = Data ∪ {▽} die Menge der Eingabesymbole und O = Data ∪ { } die Menge der 

Ausgabesymbole. Seien außerdem d ∈ Data, ds ∈ Stream Data, s ∈ Stream I. Wir charakterisieren die stromverarbeitende 

Funktion q durch: 

q(〈〉) = 〈〉 

q(〈d〉 ∧ ds ∧ 〈▽〉 ∧ s)) = 〈〉 ∧ q(ds) ∧ 〈d〉 ∧ q(s) 

q(d&ds) = &q(ds) 

An der zweiten Gleichung sehen wir, dass immer wenn ein ▽ im Eingabestrom vorkommt, das erste Element 

auf den Ausgabestrom geschrieben wird. Die Anzahl der Datenelemente im Ausgabestrom ist also stets gleich 

der ▽ Elemente im Eingabestrom. Genauso ist die Anzahl der -Elemente im Ausgabestrom gleich der Anzahl 

der Datenelemente im Eingabestrom. Wir müssen außerdem noch sicherstellen, dass die richtigen Datenelemente 

in der richtigen Reihenfolge auf den Strom geschrieben werden. 

Wir formulieren die Schnittellenzusicherung über den Eingabekanal i ∈ Stream I und den Ausgabekanal 

o ∈ Stream O. Seien außerdem x ∈ Stream I und y ∈ Stream O und n ∈ N. 

∀x, y : x ⊑ i ∧ y ⊑ o∧ ‖ x ‖=‖ y ‖⇒ 

Data#y = {▽}#x 

∧ { }#y = Data#x 

Nun sollten wir diese Zusicherungen noch auf Eingaben einschränken, die wohlgeformt sind, also nie mehr 

▽ erhalten als Daten. Dazu definieren wir: 

valid(i) :⇔ ∀z : z ⊑ i ⇒ Data#z ≥ {▽}#z

Aufgabe 3 Programmieraufgabe: Synchronisation von Prozessen 

• Bäckerei-Problem 

Beim Betreten des Geschäfts erhält jeder Kunde eine Wartenummer. Der Kunde mit der kleinsten 

Nummer wird als nächster bedient. Da es keine Garantie gibt, dass zwei Kunden nicht die gleiche 

Wartenummer kriegen, wird im Falle zwei gleicher Nummern der Prozess (Kunde) mit dem 

kleinsten Namen als erster bedient. Das bedeutet, wenn P i und P j die gleiche Nummer erhalten 

und i < j, dann wird der Prozess P i als erstes bedient. 

– Schreiben Sie ein Programm in Pseudo-Code für das Backery-Problem. 

Hinweis: Da die Prozessnamen einzigartig und total geordnet sind, ist der Algorithmus 

komplett deterministisch. 

– Schreiben Sie ein Programm für das Backery-Problem, indem Sie binäre Semaphoren benutzen. 

– Optional: Schreiben Sie ein Programm in Java, dass den gleichen Sachverhalt umsetzt und 

vergleichen Sie die 2 Programme. 

• Das Philosophen-Problem 

Fünf Philosophen sitzen gemeinsam an einem runden Tisch, an dem sie unabhängig voneinander 

von Zeit zu Zeit essen. Jeder Philosoph hat rechts neben seinem Teller nur eine Gabel, benötigt 

aber zum Essen zwei Gabeln, also auch die seines linken Nachbarn. Aus diesem Grund können nicht 

alle Philosophen gleichzeitig essen, sondern sie müssen sich bezüglich ihrer kritischen Abschnitte 

Essen synchronisieren. 

– Geben Sie eine Programmlösung unter Verwendung der P- und V-Operationen an, bei der es 

zu keinerlei Verklemmungen kommen kann. 

Hinweis: 

∗ Die Philosophen sollen als Prozesse modelliert werden 

∗ Jeder Philosoph kann sich in einem der folgende drei Zustände befinden (denkend, hungrig 

und essend)

Abbildung 7: Das Philosophen-Problem 


Backery problem 

• Lösung a) 

var choosing : array [ 0 . . . n−1] o f boolean ; 

number : array [ 0 . . . n−1] o f i n t e g e r ; 

i n i t i a l i z e choosing to f a l s e and number to 0 

repeat 

choosing [ i ]:= true ; 

number [ i ]:= max( 0 , number [ 1 ] , . . . , number [ n−1])+1 

choosing [ i ]:= f a l s e ; 

f o r j :=0 to n−1 

do begin 

while choosing [ j ] do no−op 

while number [ j ]!=0 and ( number [ j ] , j ) < ( number [ i ] , i ) do no−op ; 

end ; 

c r i t i c a l s e c t i o n ; 

number [ i ] : = 0 ; 

remainder s e c t i o n 

u n t i l f a l s e ;

• Lösung b) 

semaphore mutex ; 

semaphore s e r v e ; 

semaphore s h a r e j ; 

number : array [ 0 . . . n−1] o f i n t e g e r ; 

repeat 

P( mutex ) ; 

number [ i ]:= max( 0 , number [ 1 ] , . . . , number [ n−1])+1; 

V( mutex ) ; 

P( s h a r e j ) ; 

f o r j :=0 to n−1 

do begin 

while number [ j ]!=0 and number [ j ]

– Wenn ein Philosoph essen will, versucht er die Gabeln zu beiden Seiten seines Tellers zu bekommen. 

Schat er es, kann er für eine Zeit lang essen. Ist er mit Essen fertig, legt er die Gabeln wieder auf 

den Tisch zurück und denkt weiter nach. 

– Frage: Wie kann ein Programm aussehen, bei dem alle Philosophen immer mal wieder essen können 

und keiner am Tisch verhungert. 

• Lösungsansatz 1: 

Der naheliegendste Versuch ist, einen hungrigen Philosophen zuerst nach seiner linken Gabel greifen zu 

lassen. Sobald er die linke Gabel hat, greift er nach der rechten Gabel. Das Problem bei einer solchen 

Vorgehensweise ist dass wenn alle Philosophen gleichzeitig ihre linke Gabel schnappen, kommt es zu einer 

Verklemmung, einem Deadlock, und es geht nicht weiter. Eine modizierte Version dieser Vorgehensweise 

ist, dass ein hungriger Philosoph zuerst seine linke Gabel nimmt und dann prüft, ob die rechte Gabel 

verfügbar ist. Ist dies der Fall, kann er sie nehmen. Wenn nicht, legt er seine linke Gabel wieder zurück 

und wiederholt den Vorgang nach einer gewissen Zeit. Auch dieses Vorgehen kann zu einem Problem 

führen. Wenn alle Philosophen im Gleichtakt vorgehen, kommt es zu einem Lifelock. 


Bei einem Lifelock nimmt jeder Philosoph seine linke Gabel, stellt fest, dass die rechte Gabel nicht frei 

ist und legt die linke zurück und so weiter. In einer solchen Situation laufen die Prozesse zwar, aber sie 

kommen nicht in ihrer Abarbeitung weiter. Man spricht hier auch vom Aushungern. Eine Möglichkeit, 

die zumindest meistens funktioniert ist, dass die Philosophen eine nicht eine feste, sondern eine zufällig 

lange Zeit warten, bis sie den Vorgang wiederholen. So ist die Möglichkeit eines Lifelock sehr gering, aber 

es kann dennoch zeitweise zu einem Aushungern kommen. Eine funktionierende Möglichkeit ist, dass man 

das Aufnehmen der Gabeln, Essen und Ablegen der Gabeln als kritischen Abschnitt ansehen und unter 

gegenseitigem Ausschluss ablaufen lässt. In diesem Fall darf immer nur ein Philosoph essen, obwohl die 

Bestecke für zwei gleichzeitig essende Philosophen reichen würden 


Eine Lösung, bei der immer zwei Philosophen essen können und weder Deadlocks noch Lifelocks entstehen 

können, ist wie folgt: In einem Feld wird verfolgt, ob ein Philosoph gerade nachdenkt, isst oder hungrig 

ist, also versucht die Gabeln zu bekommen. Ein Philosoph kann nur in den Zustand essen übergehen, 

wenn seine beiden Nachbarn gerade nicht am Essen sind. Es existiert pro Philosoph ein Semaphor, so 

dass hungrige Philosophen blockieren können, falls die benötigten Gabeln in Gebrauch sind. Erst gelangt 

ein hungriger Philosoph alleine in den kritischen Bereich. Er prüft, ob seine beiden Nachbarn essen. Falls 

ja, blockiert er solange. Falls nein, beginnt er zu essen und verlässt den kritischen Bereich. Ist er fertig 

mit Essen, muss er in den kritischen Bereich kommen, seinen Status auf nachdenken setzen, die Gabeln 

freigeben und den kritischen Bereich verlassen. 

#d e f i n e N 5 /∗ Number o f p h i l o s p h e r s ∗/ 

#d e f i n e RIGHT( i ) ( ( ( i )+1) %N) 

#d e f i n e LEFT( i ) ( ( ( i )==N) 0 : ( i )+1) 

typedef enum { THINKING, HUNGRY, EATING } p h i l s t a t e ; 

p h i l s t a t e s t a t e [N ] ; 

semaphore mutex =1; 

semaphore s [N ] ; /∗ one per philosopher , a l l 0 ∗/ 

void t e s t ( i n t i ) { 

i f ( s t a t e [ i ] == HUNGRY && 

s t a t e [LEFT( i ) ] != EATING && 

s t a t e [RIGHT( i ) ] != EATING ) { s t a t e [ i ] = EATING; V( s [ i ] ) ; } 

}

void g e t f o r k s ( i n t i ) { 

P( mutex ) ; 

s t a t e [ i ] = HUNGRY; 

t e s t ( i ) ; 

V( mutex ) ; 

P( s [ i ] ) ; 

} 

void p u t f o r k s ( i n t i ) { 

P( mutex ) ; 

s t a t e [ i ]= THINKING; 

t e s t (LEFT( i ) ) ; 

t e s t (RIGHT( i ) ) ; 

V( mutex ) ; 

} 

void p h i l o s o p h e r ( i n t p r o c e s s ) { 

while ( 1 ) { 

think ( ) ; 

g e t f o r k s ( p r o c e s s ) ; 

eat ( ) ; 

p u t f o r k s ( p r o c e s s ) ; 

} 

} 

Aufgabe 4 Gezeitete Ströme 

Sei M 1 = {reset}, M 2 = {alarm}, M = {alarm, reset} und n ∈ N + . 

(a) Geben Sie einen gezeiteten Strom s über M an, so dass ∀ x ∈ N 0 : (((x>0 ⇒ (s(x) enthält reset))∧ 

(∀y ∈N + : x < y ≤ x + n ⇒ (s(y) enthält reset nicht))) ⇒ (s(x + n) enthält alarm)). 

(b) Geben Sie timeabs(s) an. 

(c) Seien I = {r} mit type(r) = M 1 die Eingabekanalmenge, O = {a} mit type(a) = M 2 die Ausgabekanalmenge. 

i) Geben Sie eine Funktion f : ⃗ I → ⃗ O, die 

i. zeitunabhängig bzw. 

ii. nicht zeitunabhängig 

ist und die folgende Schnittstellenzusicherung erfüllt: 

∀ x ∈ N 0 : (((x > 0 ⇒ (r(x) enthält reset)) ∧ (∀ y ∈ N + : x < y ≤ x + n ⇒ 

(r(y) enthält reset nicht))) ⇒ (a(x + n) enthält alarm)). 

ii) Für eine zeitunabhängige Funktion f wie oben geben Sie die Zeitabstraktion an. 

iii) Erfülle eine Funktion g : ⃗ I → ⃗ O nun die folgende Schnittstellenzusicherung: 

∀ x ∈ N 0 : (((x > 0 ⇒ (r(x) enthält reset)) ∧ (∀ y ∈ N + : x < y ≤ x + n ⇒ 

(r(y) enthält reset nicht))) ⇐⇒ (a(x + n) enthält alarm)). 

Kann g zeitunabhängig bzw. nicht zeitunabhängig sein und warum 


(a) Ein trivialer Strom ist s = λx ∈ N + . 〈alarm〉. 

Ein weniger trivialer Strom ist s ′ = λx ∈ N + . 

{ 

〈alarm reset〉 , wenn x ≡ 0 mod n , 

ɛ , 

sonst.

(b) timeabs(s) = 〈alarm alarm alarm . . .〉 und timeabs(s ′ ) = 〈alarm reset alarm reset alarm reset . . .〉. 

(c) i) • f = λs∈I. ⃗ λa∈O. λx∈N + . 〈alarm〉. 

⎧ 

Diese Funktion ( ist konstant, insbesondere zeitunabhängig. ) 

⎪⎨ 

(s(r)(1) enthält reset) ∨ 

• f = λs∈I. ⃗ 〈alarm〉 , wenn 

, 

λa∈O. λx∈N + . 

(x>n ∧ (s(r)(x − n) enthält reset)) 

⎪⎩ 

ɛ , sonst. 

ist nicht zeitunabhängig. { Denn betrachte zwei Belegungen von I 

〈reset〉 , wenn x=1 , 

s 1 = λr ∈I. λx∈N + . 

ɛ , sonst 

und 

{ 

〈reset〉 , wenn x=2 , 

s 2 = λr ∈I. λx∈N + . 

ɛ , sonst. 

Es gilt timeabs(s 1 )(r) = 〈reset〉 = timeabs(s 2 )(r). Aber 

f(s 1 ) = λa∈O. λx∈N + . 〈alarm〉 { und 

〈alarm〉 , wenn x=n+2 , 

f(s 2 ) = λa∈O. λx∈N + . 

ɛ , sonst , 

also timeabs(f(s 1 )(a)) = alarm ∞ ≠ 〈alarm〉 = timeabs(f(s 2 )(a)). 

ii) Zum Beispiel λx ∈ M ω . λy ∈N + . 〈alarm〉 oder λx ∈ M ω . λy ∈{1, 2}. 〈alarm〉. 

iii) Wir zeigen, dass so ein { g immer nicht zeitunabhängig ist. Seien 

〈reset〉 , wenn x ≡ 0 mod (n+1) , 

t 1 = λr ∈I. λx∈N + . 

ɛ , sonst. 

und 

t 2 = λr ∈I. λx∈N + . 〈reset〉. 

Dann timeabs(t 1 (r)) = reset ∞ = timeabs(t 2 (r)). Nun gibt es gibt eine Funktion h: N + → N 0 , so 

dass 

{ 

〈alarm h(x) 〉 , wenn x ≡ n mod (n + 1) , 

g(t 1 )(a) = λx∈N + . 

ɛ , 

sonst, 

timeabs(g(t 1 )(a)) = alarm ∞ , 

g(t 2 )(a) = λx∈N + . ɛ und 

timeabs(g(t 2 )(a)) = ɛ. Also 

timeabs(g(t 1 )(a)) ≠ timeabs(g(t 2 )(a)). 

Ein Beispiel einer solchen Abbildung 

⎧ 

ist ( 

) 

⎪⎨ 

(x=n ∨ (x>n ∧ (s(r)(x−n) enthält reset))) ∧ 

g = λs∈I. ⃗ 〈alarm〉 , wenn 

, 

λa∈O. λx∈N + . 

(∀y ∈ N + ∩ (x − n, x]: s(r)(y) enthält reset nicht) 

⎪⎩ 

ɛ , sonst.

Â¨Ubungen zu â Modellierung verteilter Systemeâ

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?

Â¨Ubungen zu â Modellierung verteilter Systemeâ