Entwicklung von Telekommunikationssystemen
Download
Report
Transcript Entwicklung von Telekommunikationssystemen
Ü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
Entwurf von Telekommunikationssystemen
- 232 -
tele
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
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]
Entwurf von Telekommunikationssystemen
- 233 -
tele
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)
Entwurf von Telekommunikationssystemen
- 234 -
tele
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
Entwurf von Telekommunikationssystemen
- 235 -
tele
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)
}
Entwurf von Telekommunikationssystemen
- 236 -
tele
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)
}
Entwurf von Telekommunikationssystemen
- 237 -
tele
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)->
Entwurf von Telekommunikationssystemen
- 238 -
tele
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/nonblocking 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)
Entwurf von Telekommunikationssystemen
- 239 -
tele
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
Entwurf von Telekommunikationssystemen
- 240 -
tele
Promela Sprachdefinition
Sprünge
proctype Euclid (int x, y) {
do
:: (x > y) -> x = x-y
:: (x < y) -> y = y-x
:: else -> goto done
od
done:
skip }
Entwurf von Telekommunikationssystemen
- 241 -
tele
Promela Sprachdefinition
Datentypen
Typ
bit oder bool
byte
short
int
Deklarationen
Bereich
{0, 1}
0 .. 255
-2 .. 2-1
-2 .. 2-1
type name = expression
type name [constant] = expression
expression: default
[constant]: Deklaration eines Array
Entwurf von Telekommunikationssystemen
- 242 -
tele
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);
ncrit--;
/* critical section */
flag[_pid] = 0;
goto again
}
Entwurf von Telekommunikationssystemen
- 243 -
tele
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)
Entwurf von Telekommunikationssystemen
- 244 -
tele
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
Entwurf von Telekommunikationssystemen
- 245 -
tele
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?
Entwurf von Telekommunikationssystemen
- 246 -
tele
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]
Entwurf von Telekommunikationssystemen
- 247 -
tele
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; …
Entwurf von Telekommunikationssystemen
- 248 -
tele
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}
?
Entwurf von Telekommunikationssystemen
- 249 -
tele
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
Entwurf von Telekommunikationssystemen
- 250 -
tele
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
}
Entwurf von Telekommunikationssystemen
- 251 -
tele
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;}
Entwurf von Telekommunikationssystemen
- 252 -
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}
tele
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
Entwurf von Telekommunikationssystemen
- 253 -
tele
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
Entwurf von Telekommunikationssystemen
- 254 -
tele
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]
Entwurf von Telekommunikationssystemen
- 255 -
tele
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
Entwurf von Telekommunikationssystemen
- 256 -
tele
Kontrollzustandsprädikate
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}
Beispiele
(at_crit count = 1)
at_enter
Konkrete Promela/SPIN Syntax später
Entwurf von Telekommunikationssystemen
- 257 -
tele
Kontrollzustandsprädikate
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}
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
Entwurf von Telekommunikationssystemen
- 258 -
tele
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
Entwurf von Telekommunikationssystemen
- 259 -
tele
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?
Entwurf von Telekommunikationssystemen
- 260 -
tele
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?
Entwurf von Telekommunikationssystemen
- 261 -
tele
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;
Entwurf von Telekommunikationssystemen
- 262 -
tele
Eigenschaftsspezifikation in Promela
Globale Invariante mittels assert:
#define p
0
#define v
1
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()
}}
Entwurf von Telekommunikationssystemen
- 263 -
tele
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
}
Entwurf von Telekommunikationssystemen
- 264 -
tele
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}
Entwurf von Telekommunikationssystemen
- 265 -
tele
Eigenschaftsspezifikation in Promela
Temporal oder Never Claims (Niemals-Behauptungen)
Möglichkeit, temporale Korrektheitseigenschaften direkt als BüchiAutomaten 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
never{ do
:: skip
/* true */
:: p -> break /* p */
od;
accept: do
:: p
/* p */
od }
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
Entwurf von Telekommunikationssystemen
- 266 -
tele
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
}
Entwurf von Telekommunikationssystemen
- 267 -
tele
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
Entwurf von Telekommunikationssystemen
- 268 -
tele
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
Entwurf von Telekommunikationssystemen
- 269 -
tele
Validationsalgorithmen
Beispiel eines LTS:
(C, A) = (x = true, x = x)
s
(C, A) = (x = false, x = x)
Entwurf von Telekommunikationssystemen
- 270 -
tele
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)(vg P.Dg.V) (gültige Objektwerte)
3. (h|1 h n)(wh P.Dh.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)
Entwurf von Telekommunikationssystemen
- 271 -
tele
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 SS
Beispiel:
s, true
Entwurf von Telekommunikationssystemen
s, false
- 272 -
tele
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, PrenticeHall, 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 OperationalSemantics 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)
Entwurf von Telekommunikationssystemen
- 273 -
tele