Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Gitta Emilia Messner Geändert vor über 8 Jahren
1
tele Entwurf von Telekommunikationssystemen- 232 - Übersicht 1. Einführung in den Software-Entwurfsprozess 2. Anforderungsspezifikation mit Zustandsmaschinen 3. Anforderungsspezifikation mit Linearer Temporaler Logik 4. Automatenbasiertes Model Checking 5. Die Modellierungssprache Promela und der SPIN Model Checker 6. Effizienzsteigernde Massnahmen 7. Anwendungsbeispiele von SPIN Model Checking 8. Eine visuelle Entwicklungsumgebung für Promela/Spin 9. Verwandte, semi-formale Modellierungsmethoden
2
tele Entwurf von Telekommunikationssystemen- 233 - Promela Protocol (oder Process) Meta Language SPIN Model Checker Simulation und Validation von Promela Modellen XSPIN: Graphisches Interface zu SPIN Entwickelt von Gerard Holzmann, Bell Laboratories Web Site http://netlib.bell-labs.com/netlib/spin/whatisspin.html http://netlib.bell-labs.com/netlib/spin/whatisspin.html Zugang zu Software –Open Source C Code –Benutzt gcc, Tcl/Tk, dotty –Compilierbar unter Solaris und Linux –Windows Binaries verfügbar Dokumentation und Literaturverweise –[Holzmann 91] –[Holzmann 95] –[Holzmann 97]
3
tele Entwurf von Telekommunikationssystemen- 234 - Promela Ziel Modellierungssprache für Kommunikationsprotokolle –“A model represents and abstraction that contains only those aspects of a design that are relevant to the properties one is interested in proving.” –“A model contains things that are typically not part of an implementation” (siehe [Holzmann 95]) Wurzeln im Protocol Engineering, aber in jüngerer Vergangenheit verstärkt Anwendungen auch in anderen Gebieten –Diverse Kommunikationsprotokolle –Steuerungssoftware für Sturmwehr für den Hafen von Rotterdam –Philips HiFi Kontrollsystem –Bosch/Blaupunkt CAM Protokol –NASA PathFinder –JAVA Code und Bytecode Model Checking –Flugkontroll-Logik –Telekommunikations-Dienste (PathStar, Distributed Feature Composition)
4
tele Entwurf von Telekommunikationssystemen- 235 - Promela Sprachdefinition Objekte nebenläufige Prozesse ( proctype ) Variablen über endlichen Domänenbereichen Nachrichtenkanäle endlicher Länge Wichtig: alle Objekte müssen deklariert werden, bevor sie benutzt werden können Scope Prozesse: immer global Variablen und Kanäle: global oder lokal für einen Prozess
5
tele Entwurf von Telekommunikationssystemen- 236 - Promela Sprachdefinition Prozesse init{ printf(“it works\n”) } init : instanziiert einen Prozess printf : eingebaute Funktion Prozess-Abstraktion proctype my_x (byte x) { printf("my x is: %d\n", x) } init { run my_x (0); run my_x (1) }
6
tele Entwurf von Telekommunikationssystemen- 237 - Promela Sprachdefinition Instanziierung nur einer Prozessinstanz zur Anfangszeit des Systems proctype my_x (byte x) { printf("my x is: %d\n", x) } active proctype main() { run my_x (0); run my_x (1) } Mehrere Instanzen eines Prozesses active [2] proctype my_x() { printf("my _pid is: %d\n", _pid) }
7
tele Entwurf von Telekommunikationssystemen- 238 - Promela Sprachdefinition Ausführungssemantik Guarded-command Sprache (à la Dijkstra) begin loop g1 -> s1 g2 -> s2 … gn -> sn end loop Mehr als ein Guard ist wahr? Wie implementiert man sequentielle Ausführung? In Promela: –eine Anweisung ist immer entweder auführbar, oder blockiert in sequentieller Programmiersprache while a not = b do od; entspricht in Promela (a == b); oder (a == b)->
8
tele Entwurf von Telekommunikationssystemen- 239 - Promela Sprachdefinition Ausführungsbedingungen Bedingung: wenn Bedingung wahr ist Zuweisung, printf : immer run : falls eine neue Prozessinstanz generiert werden kann (Laufzeitbeschränkung auf 256 Prozessinstanzen) Lesen von einem asynchronen Kanal: wann immer eine Nachricht des erwarteten Typs am Kopf der Warteschlange angelangt ist Schreiben in einen asynchronen Kanal: –immer bei nicht vollem Kanal –bei vollem Kanal parametrisiert, abhängig von blocking/non- blocking Semantik für vollen Kanal Lesen/empfangen von einem synchronen Kanal: wann immer der Synchronisationspartner zu einem Handshake bereit ist Mehr als eine auführbare Anweisung zu einem gegebenen Zeitpunkt Bei Simulation entscheidet Laufzeit-Scheduler zufällig über die Auswahl Es wird zu jedem Zeitpunkt nur eine Anweisung ausgeführt (Interleaving Semantik)
9
tele Entwurf von Telekommunikationssystemen- 240 - Promela Sprachdefinition Kontrollfluss-Beispiele Fallentscheidung if :: (a != b) -> option1 :: (a = b) -> option2 fi; –blockiert, bis zumindest eine der auf ein :: folgenden Anweisungen auführbar ist –zufällige Auswahl bei mehr als einer ausführbaren Anweisung –spezieller Guard else kann genau einmal pro if.. fi als erster Teil einer Anweisung verwendet werden, else ist genau dann wahr, wenn alle anderen guards nicht wahr sind Schleife (undendliche Wiederholung) do :: (count != 0) -> if :: count = count + 1 :: count = count - 1 fi :: else -> break od –wie if.. fi –unendliche Wiederholung bis break oder goto
10
tele Entwurf von Telekommunikationssystemen- 241 - Promela Sprachdefinition Sprünge proctype Euclid (int x, y) { do :: (x > y) -> x = x-y :: (x y = y-x :: else -> goto done od done: skip }
11
tele Entwurf von Telekommunikationssystemen- 242 - Promela Sprachdefinition Datentypen Typ Bereich bit oder bool {0, 1} byte 0.. 255 short -2 .. 2 -1 int -2 .. 2 -1 Deklarationen type name = expression type name [constant] = expression expression : default [constant] : Deklaration eines Array
12
tele Entwurf von Telekommunikationssystemen- 243 - Promela Sprachdefinition Petersen's Mutual Exclusion bool turn, flag[2]; byte ncrit; active [2] proctype user() { assert(_pid == 0 || _pid == 1); again: flag[_pid] = 1; turn = _pid; (flag[1 - _pid] == 0 || turn == 1 - _pid); ncrit++; assert(ncrit == 1);/* critical section */ ncrit--; flag[_pid] = 0; goto again }
13
tele Entwurf von Telekommunikationssystemen- 244 - Promela Sprachdefinition Datenstrukturen typedef Field { short f = 3; byte g } typedef Msg { byte a[3]; int fld1; Field fld2; bit b }; Msg message; … message.a[2] = message.fld2.f + 12 … proctype me (Msg z) {…} … run me(message)
14
tele Entwurf von Telekommunikationssystemen- 245 - Promela Sprachdefinition Mehrdimensionale Arrays typedef Array { byte el[4] }; Array a[4]; … a[i].el[j] Ausdrücke alle Ausdrücke müssen frei von Seiteneffekten sein (keine Zuweisungen zu Variablen beinhalten) bedingter Ausdruck (expr1 -> expr2 : expr3) –kann in Zuweisungen benutzt werden
15
tele Entwurf von Telekommunikationssystemen- 246 - Promela Sprachdefinition Nachrichtenkanäle beliebige, endliche Anzahl von eindirektionalen Kanälen Nachrichtentypen mtype{ack, req, done, alert} wird übersetzt in Byte-Werte 1, 2, 3, 4 endliche Kapazität, bekannt zur Zeit der Übersetzung chan qname = [16] of {mtype, byte, bool} oder chan qname = [16] of {byte, byte, bool} oder #define QUSIZE … chan qname = [QUSIZE] of {mtype, byte, bool} senden/empfangen qname!expr1,expr2,expr3 qname?var1,var2,var3 –Ausführbarkeit?
16
tele Entwurf von Telekommunikationssystemen- 247 - Promela Sprachdefinition Kommunikationsprimitive Typen von Kommunikationsanweisungen –nicht-blockierend: die Ausführung verzögert nie den aufrufenden Prozess –blockierend: andernfalls Wann sind Sende- bzw. Empfangsanweisungen blockierend oder nicht-blockierend? –Asynchrone Nachrichtenübermittlung: Puffer mit unbeschränkter Speicherkapazität (Sender kann dem Empfänger eine unbeschränkte Anzahl von Schritten überholen) Sender nie blockiert –Synchrone Nachrichtenübermittlung: keine Pufferung, Sendeprimitiv blockiert bis Empfänger zum Empfang bereit –Gepufferte Nachrichtenübermittlung: Puffer mit beschränkter, endlicher Kapazität Sender blockiert bei vollem Puffer Sender blockiert nicht bei vollem Puffer (Nachrichtenverlust) In Promela? Siehe auch [Andrews and Schneider, Kap. 4.2]
17
tele Entwurf von Telekommunikationssystemen- 248 - Promela Sprachdefinition Kommunikationsprimitive Selektives Empfangen: Match der ersten Komponente einer empfangenen Nachricht qname?cons1, var2, cons3 empfangener Wert muss mit dem Wert der lokal definierten Konstante übereinstimmen qname?mtype1, var2, cons3 empfangener Nachrichtentyp muss mit dem lokal definierten Nachrichtentyp übereinstimmen Abfage der derzeitigen Länge eines Kanals len(qname) empty(qname) full(qname) Feststellung des Kopfelements eines Kanals –nur möglich für asynchrone Kanäle –syntaktisch nicht zulässig: ((a -> b) && qname?msg0) -> … –zulässige Variante ((a -> b) && qname?[msg0]) -> qname?msg0; …
18
tele Entwurf von Telekommunikationssystemen- 249 - Promela Sprachdefinition Kommunikationsprimitive Schutz gegen senden in vollen Kanal !full(qname) -> qname!msg0 Synchrone Kommunikation (Rendezvous) mtype = {req} chan port = [0] of {mtype} active proctype sender() {port!req; port!req} active proctype receiver() {port?req} Verhalten von... chan port = [1] of {mtype} chan port = [10] of {mtype} ?
19
tele Entwurf von Telekommunikationssystemen- 250 - Promela Sprachdefinition Atomizität zusammengestzter Anweisungen Probleme bei –qname?[msg0] -> qname?msg0 –!full(qname) -> qname!msg0 Lösung: atomic –atomic {qname?[msg0] -> qname?msg0} –atomic {!full(qname) -> qname!msg0} –atomic { /*swap a and b */ tmp = b; b = a; a = tmp } –Semantische Bedingungen Anweisungen innerhalb atomic können nichtdeterministisch sein Blockieren einer Anweisung -> Atomizität unterbrochen Wenn Kontrolle zu dem unterbrochenen Prozess zurückkehrt, dann wird Atomizität von dem Unterbrechungspunkt an wieder hergestellt Synchrone Kommunikation -> Atomizität geht auf den Empfänger über, falls dieser innerhalb atomic empfängt, Rückkehr möglich Effizientere Variante: d_step, muss deterministisch sein
20
tele Entwurf von Telekommunikationssystemen- 251 - Promela Sprachdefinition Nebenläufige Initialisierung von Prozessen init { atomic {run user(s_to_u, u_to_s); run server(u_to_s, s_to_u)} } Prozedurale Abstraktion: inline inline recv(cur_msg, cur_ack, lst_msg, lst_ack) { do :: receiver?cur_msg -> sender!cur_ack; break /* accept */ :: receiver?lst_msg -> sender!lst_ack od; } active proctype Receiver() { do :: recv(msg1, ack1, msg0, ack0); recv(msg0, ack0, msg1, ack1) od }
21
tele Entwurf von Telekommunikationssystemen- 252 - Promela Sprachdefinition Beispiel: AB-Protokoll ([Holzmann 00]) mtype = { msg0, msg1, ack0, ack1 }; chan sender = [1] of { mtype }; chan receiver = [1] of { mtype }; inline phase(msg, good_ack, bad_ack) { do :: sender?good_ack -> break :: sender?bad_ack :: timeout -> if :: receiver!msg; :: skip /* lose message */ fi; od } inline recv(cur_msg, cur_ack, lst_msg, lst_ack) { do :: receiver?cur_msg -> sender!cur_ack; break /* accept */ :: receiver?lst_msg -> sender!lst_ack od;} active proctype Sender() { do :: phase(msg1, ack1, ack0); phase(msg0, ack0, ack1) od} active proctype Receiver() { do :: recv(msg1, ack1, msg0, ack0); recv(msg0, ack0, msg1, ack1) od}
22
tele Entwurf von Telekommunikationssystemen- 253 - Promela Sprachdefinition Timeout Keine Echtzeit in Promela timeout -> … timeout wird ausführbar, wenn in dem gesamten Modell keine einzige Anweisung ausführbar ist (Beendigung von deadlock Zuständen) proctype watchdog () { do :: timeout -> guard!reset od } Escape Sequenz { P } unless { E } (P und E sind beliebige Promela Fragmente) Semantik –der erste Guard von E wird nach jeder Anweisung in P auf Ausführbarkeit evaluiert –P wird terminiert, sobald E ausführbar wird, und E wird dann sofort ausgeführt –E wird übersprungen, falls es nie auführbar wird
23
tele Entwurf von Telekommunikationssystemen- 254 - Promela Sprachdefinition Abschliessende Bemerkungen Lediglich Prozess-Rekursion, Gefahr des Stack-Überlaufs Lediglich inline als prozedurale Abstraktion, entspricht syntaktischer Ersetzung Promela kennt keine Umgebung, alle Modelle repräsentieren geschlossene Systeme SDL-artige Zustandsmaschinen können zur Dokumentation von Promela Modellen verwendet werden (siehe [Holzmann 91], aber SDL und Promela haben sehr unterschiedliche Semantik
24
tele Entwurf von Telekommunikationssystemen- 255 - Semantik Wann erfüllt … ein Zustand s eines Promela Programms eine LTL Formel f? Interpretation eines Promela-Modells als ein Zustandstransitionssystem –Asynchrone Kombination von CEFSMs –Bildung des asynchronen Produktes der Komponenten-CEFSMs (siehe z.B. Semantik à la [Brand and Zafiropulo]) Ansatz zur Definition einer formalen Semantik in [Natarajan und Holzmann] basierend auf Precondition/Effect Paaren Skizze zur Ableitung eines Zustands-Transitionssystems für eine nebenläufige, asynchrone Progammiersprache siehe [Clarke, Grumberg and Peled, Kapitel 2]
25
tele Entwurf von Telekommunikationssystemen- 256 - Kontrollzustandsprädikate Spezifikation von Eigenschaften eines Promela Programms Zustandsprädikte: sind für einzelne Zustände gültig “ein Prozess befindet sich im kritischen Abschnitt” Transitionsprädikate: sind für Paare von Zuständen gültig “der Zustand q’ des Kanals nach dem Senden von x ist gleich x konkateniert mit dem Zustand q des Kanals vor senden von x” Zustandsmarkierungen Bei der Spezifikation von Zustandsprädikaten kann es sehr hilfreich sein, auf Kontrollzustände von Promela Programmen verweisen zu können Sei S eine Anweisung in einem nebenläufigen Programm P, dann ist ( , i) at_S gültig, falls sich die Kontrolle von P in s vor der Ausführung von S befindet in Promela: Anweisungen können mit Markierungen versehen werden
26
tele Entwurf von Telekommunikationssystemen- 257 - Kontrollzustandsprädikate Beispiele (at_crit count = 1) at_enter Konkrete Promela/SPIN Syntax später mtype { p, v}; chan sema = [0] of { mtype }; active proctype Dijkstra() {byte count = 1; do :: (count == 1) -> sema!p; count++ :: (count == 0) -> sema?v; count-- od} active [3] proctype user() { do :: enter: sema?p; /* enter critical section */ crit: skip; /* critical section */ sema!v; /* leave critical section */ od}
27
tele Entwurf von Telekommunikationssystemen- 258 - Kontrollzustandsprädikate Kontrollzustandsprädikat after after_S gültig in dem Zustand direkt nach Ausführung von S enter: sema?p; crit: skip; after_enter at_crit wird nicht direkt von Promela unterstützt mtype { p, v}; chan sema = [0] of { mtype }; active proctype Dijkstra() {byte count = 1; do :: (count == 1) -> sema!p; count++ :: (count == 0) -> sema?v; count-- od} active [3] proctype user() { do :: enter: sema?p; /* enter critical section */ crit: skip; /* critical section */ sema!v; /* leave critical section */ od}
28
tele Entwurf von Telekommunikationssystemen- 259 - Kontrollzustandsprädikate at und after in sequentiellen Programmsegmenten S ; S after_S at_S in verzweigenden Programmsegmenten (hier jetzt Unterscheidung zwischen Anweisung i und der korrespondierenden Markierung L ) L : G -> atomic{S ; goto L } after_ L at_L in in_L nur sinnvoll für Anweisungen, die Teilanweisungen enthalten In Promela at, after, in nicht direkt unterstützt müssen durch Kontrollzustandsmarkierungen simuliert werden at am leichtesten emulierbar
29
tele Entwurf von Telekommunikationssystemen- 260 - Eigenschaftsspezifikation in Promela Deadlock Das System befindet sich in einem globalen Systemzustand, in dem keine Transition auführungsbereit ist. Typischerweise: "deadly embrace" proctype P1 (fromP2, proctype P2 (fromP1, toP2) toP1) {… fromP2?a; fromP1?b; … toP2!b; toP1!a; … } Analyse –statisch: Suche nach Zyklen im Nachrichten- und Kontrollflussgraphen –Zustandsmaschine: Suche nach allen globalen Systemzuständen, die keinen Nachfolgezustand haben –Sicherheit / Lebendigkeit?
30
tele Entwurf von Telekommunikationssystemen- 261 - Eigenschaftsspezifikation in Promela Livelock Das System befindet sich in einer zyklischen Aufsührungsfolge, ohne sichtbaren Fortschritt zu machen Definition, was "Fortschritt" heisst Unerwünschte Terminierung Das System terminiert in einem unerwünschten Endzustand –Kanäle nicht leer? –Mitten im Prozessverhalten?
31
tele Entwurf von Telekommunikationssystemen- 262 - Eigenschaftsspezifikation in Promela Correctness Claims (Korrektheitsbehauptungen) in Promela assert(conditional_expression) Semantik: –immer ausführbare Anweisung –Ausführung des Systems bricht mit einer "assertion violation" ab, wenn die conditional_expression bei Ausführung der assert Anweisung falsch ist assert(x != 0); b == n / x;
32
tele Entwurf von Telekommunikationssystemen- 263 - #define p0 #define v1 chan sema = [0] of { bit }; proctype dijkstra() {do :: sema!p -> sema?v od} byte count; proctype user() {sema?p; count = count+1; skip;/* critical section */ count = count-1; sema!v; skip/* non-critical section */ } proctype monitor() { assert(count == 0 || count == 1) } init {atomic { run dijkstra(); run monitor(); run user(); run user(); run user() }} Eigenschaftsspezifikation in Promela Globale Invariante mittels assert:
33
tele Entwurf von Telekommunikationssystemen- 264 - Eigenschaftsspezifikation in Promela End State Labels (Endzustandsmarkierungen) Terminierung kann auch für Reaktive Systeme gewollt sein Voranstellung von "end" vor den Namen einer Zustandsmarkierung bedeutet, dass das Promela-Modell in diesem lokalen Zustand terminieren darf Wenn das Modell terminiert, und sich alle proctype Instanzen in einem "end"-Zustand befinden, dann befindet sich das Modell in einem erlaubten Terminierungszustand, andernfalls "invalid end state" –Ausführungsparameter (SPIN): alle Kanäle müssen leer sein, oder nicht active proctype Dijkstra() {byte count = 1; enddijkstra: do :: (count == 1) -> sema!p; count = 0 :: (count == 0) -> sema?v; count = 1 od }
34
tele Entwurf von Telekommunikationssystemen- 265 - Eigenschaftsspezifikation in Promela Progress State Labels (Fortschrittsmarkierungen) Prozesse können sich in Endlosschleifen bewegen, ohne jemals für den Benutzer beobachtbaren Fortschritt zu erzielen Voranstellung von progress vor den Namen einer Zustandsmarkierung bedeutet, dass jede zyklische Auführungsfolge des Promela Modells durch mindestens einen lokalen Fortschrittszustand führen muss, andernfalls "non-progress-cycle" mtype { p, v}; chan sema = [0] of { mtype } active proctype Dijkstra() {byte count = 1; end:do :: (count == 1) -> progressdijkstra: sema!p; count = 0 :: (count == 0) -> sema?v; count = 1 od} active [3] proctype user() {do :: sema?p; /* enter critical section */ crit: skip; /* critical section */ sema!v; /* leave critical section */ od}
35
tele Entwurf von Telekommunikationssystemen- 266 - Eigenschaftsspezifikation in Promela Temporal oder Never Claims (Niemals-Behauptungen) Möglichkeit, temporale Korrektheitseigenschaften direkt als Büchi- Automaten zu Beschreiben Promela Modell und Never Claim werden als synchrones Produkt ausgeführt Beispiel: p soll nie unendlich lange wahr sein –Negation: p ist irgendwann immer wahr accept: Büchi Akzeptierungbedingung Never claim kann beliebige, Seiteneffekt-freie Ausdrücke beinhalten Auch erlaubt: end, progress, assert Programmierung von never claims praktisch recht schwierig, daher häufig bietet SPIN eine LTL -> never claim Übersetzung never{do :: skip /* true */ :: p -> break /* p */ od; accept:do :: p /* p */ od }
36
tele Entwurf von Telekommunikationssystemen- 267 - Eigenschaftsspezifikation in Promela LTL nach never claim Konvertierung /* * Formula As Typed: [] (t1 -> <> c1) * The Never Claim Below Corresponds * To The Negated Formula !([] (t1 -> <> c1)) * (formalizing violations of the original) */ never { /* !([] (t1 -> <> c1)) */ T0_init: if :: (1) -> goto T0_init :: (! ((c1)) && (t1)) -> goto accept_S4 fi; accept_S4: if :: (! ((c1))) -> goto T0_S4 fi; T0_S4: if :: (! ((c1))) -> goto accept_S4 fi; accept_all: skip }
37
tele Entwurf von Telekommunikationssystemen- 268 - Validationsalgorithmen Transitionssystem Wir nennen das Tripel (S, s , E) mit –S: endliche Zustandsmenge –s : Initialzustand –E S S: Menge von Transitionen ein Transitionssystem (TS). Datenobjekt Wir nennen ein Tupel (V, v ) mit –V: endliche Menge möglicher Objektwerte –v V: Initialwert ein Datenobjekt. Seiteneffekt-freier Ausdruck ist ein Ausdruck ohne Zweisung zu Datenobjekten
38
tele Entwurf von Telekommunikationssystemen- 269 - Validationsalgorithmen Kantenmarkierung Ein Tupel (C, A) mit –C: eine durch einen seiteneffektfreien Ausdruck spezifizierte Bedingung –A: eine atomare Aktion, z.B. eine Zuweisung nennen wir eine Kantenmarkierung Markiertes Transitionssystem (Labeled Transistion System, LTS) Ein Quadrupel (T, D, L, F) ist ein LTS, wobei –T: ein Transitionssystem –D: eine endliche, geordnete Menge von Datenobjekten –L: eine Menge von Kantenmarkierungen –F: eine Markierungsfunktion T.E L ist
39
tele Entwurf von Telekommunikationssystemen- 270 - (C, A) = (x = true, x = x) (C, A) = (x = false, x = x) ss Validationsalgorithmen Beispiel eines LTS:
40
tele Entwurf von Telekommunikationssystemen- 271 - Validationsalgorithmen Expandierter Zustand eines LTS P ist eine geordnete Menge (s , v , … v ) mit –s P.T.S (Kontrolle), und –v P.D .V j = 1..n (Daten) Datenkonsistenz Ein Paar –(s , v , … v ) –(s , w , … w ) von expandierten Zuständen für ein gegebenes LTS P wird als datenkonsistent bezeichnet, falls 1. (s , s ) P.T.E (Nachfolgezustände) 2. ( g|1 g n)(v g P.D g.V) (gültige Objektwerte) 3. ( h|1 h n)(w h P.D h.V) (gültige Objektwerte) 4. P.F(s , s ).C(v , … v ) = true (Transitionsbedingung wahr) 5. ( k|1 k n)(P.F(s , s ).A (v ,..,v ) = w ) (w enthält Datenwerte nach Transition)
41
tele Entwurf von Telekommunikationssystemen- 272 - Validationsalgorithmen Expandiertes LTS (ELTS) Die Expansion eines LTS P ist ein Tupel X=(S, s , E), wobei S = P.T.S P.D .V .. P.D.V (alle Kontroll- und Datenkombinationen) s = (P.T.s , P.D .v ,.., P.D.v ) (initiale Kontroll- und Datenzustände) E ist die Menge aller datenkonsistenten Paare in S S Beispiel: s , trues , false
42
tele Entwurf von Telekommunikationssystemen- 273 - Bibliographische Referenzen [Andrews and Schneider] G. Andrews and F. Schneider, Concepts and Notations for Concurrent Programming, Computing Surveys, Vol. 15, No. 1, March 1983 [Clarke, Grumberg and Peled] E. Clarke, O. Grumberg and D. Peled, Model Checking, MIT Press, Cambridge, 1999 [Holzmann 91] G. Holzmann, Design and Validation of Computer Protocols, Prentice- Hall, 1991 [Holzmann 93] Tutorial: Design and Validation of Protocols, Computer Networks and ISDN Systems, Vol. 25, No. 9, pp. 981-1017, 1993 [Holzmann 95] G. Holzmann, The Verification of Concurrent Systems, unpublished manuscript, AT&T Inc., 1995 [Holzmann 97] G. Holzmann, The Model Checker SPIN, IEEE Transactions on Software Engineering, Vol. 23, No. 5, May 1997 [Holzmann 00] G. Holzmann, personal communication, 2000. [Natarajan and Holzmann] V. Natarajan and G. Holzmann, Outline for an Operational- Semantics Definition for PROMELA, in: J.-C. Grégoire, G. Holzmann and D. Peled (eds.), The SPIN Verification System - Proceedings of the Second Workshop on the SPIN Verification System, DIMACS Series in Discrete Mathematics and Theoretical Computer Science, Vol. 32, AMS, 1996. (Postscript available)Postscript available
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.