La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Slide 1 [GJM91, Cap. 6] [BB87] [P93] Appunti u 1. Verifica di equivalenze per algebre di processo u 2. Dimostrazione di correttezza di programmi u 3. Esecuzione.

Presentazioni simili


Presentazione sul tema: "Slide 1 [GJM91, Cap. 6] [BB87] [P93] Appunti u 1. Verifica di equivalenze per algebre di processo u 2. Dimostrazione di correttezza di programmi u 3. Esecuzione."— Transcript della presentazione:

1 Slide 1 [GJM91, Cap. 6] [BB87] [P93] Appunti u 1. Verifica di equivalenze per algebre di processo u 2. Dimostrazione di correttezza di programmi u 3. Esecuzione simbolica Lezione 15. Verifica (II) [P93] V. R. Pratt, Logics of Programs, in A. Ralston, E. D. Reilly (Eds.) Encyclopedia of Computer Science, IEEE Press, pp. 791

2 Slide 2 1. Verifica di equivalenze per algebre di processo u La natura algebrica di questi linguaggi offre maggior varietà di strumenti di analisi rispetto ai modelli a stati finiti manipolazione e trasformazione di espressioni algebriche mediante leggi algebriche e assiomatizzazioni di relazioni manipolazione diretta di Labelled Transition Systems derivati dalla semantica formale

3 Slide 3 u Tipico problema di verifica per specifiche LOTOS: verifica di equivalenza osservazionale fra specifiche sintatticamente diverse. u Esempio dallarchitettura OSI: UpperService LowerService P Entity a b cd hide c, d in ((P[a, c] ||| P[b, d]) |[c, d]| LowerService[c, d]) UpperService[a, b] ?

4 Slide 4 Equivalenza osservazionale u Un pianista (= osservatore) prova un tasto alla volta… u … che risulta premibile o bloccato in base alla partitura precedentemente inserita u Bechstain Bluthner se nessun pianista cieco li può distinguere do sol mi sol u La classica equivalenza fra automi (come riconoscitori di linguaggi) è inadeguata: la musica possibile sui due strumenti è la stessa: {-, do, do-mi, do-sol}… u … ma i comportamenti rispetto a deadlock sono diversi: do-mi può fallire sul Bluthner, non sul Bechstain Bluthner Bechstain

5 Slide 5 u Action sequence: --- ( 1... n ) ---> [ k Gates i ] (1)---(do, mi)--->(4) (1)---(i, do)--->(5) (1) >(1) u Observable action sequence: === (a 1... a n ) ==> [a k Gates] (1)==(do, mi)==>(4) (1)==(do, mi)==>(8) (1)== ==>(1) (1)== ==>(3) do mi i do sol i mi

6 Slide 6 u Una relazione R fra stati di un LTS è una weak bisumulation se: (p, q) R, s Gates* » p tale che p==s==>p »( q tale che q==s==>q /\ (p, q) R) »/\ » q tale che q==s==>q »( p tale che p==s==>p /\ (p, q) R) u p e q sono observation equivalent (p q) se una weak bisimulation R tale che »(p, q) R

7 Slide 7 Due LTS equivalenti e la loro bisimulazione PQ aa bi c c a bi c Bisimulazione R P Q

8 Slide 8 u Lequivalenza fra stati di LTS ne induce una fra espressioni di algebre di processo u Una congruenza è una equivalenza preservata quando si rimpiazza una sotto-espressione con unaltra sotto-espressione equivalente. Formalmente: u Un contesto, denotato C[ ], è una espressione in cui una sotto- espressione è rimpiazzata da un segna-posto ([ ]) u B1 observation congruent B2 (B1 c B2) se per ogni contesto C[ ]: C[B1] C[B2] (che implica C[B1] c C[B2]…)

9 Slide 9 Se Allora c c

10 Slide 10 Leggi della congruenza osservazionale u Per CCS o Basic LOTOS non è possibile fornire una assiomatizzazione di c [M84] u Invece, per finitary LOTOS (e, analog., f. CCS), comprendente solo action prefix, choice, stop lassiomatizzazione è possibile, mediante il sistema completo e consistente di leggi [HM85]: (a1)B [] (C [] D)= (B [] C) [] D (a1)B [] C= C [] B (a3)B [] B= B (a4)B [] stop= B (a5)B [] i; B= i; B (a6) (B [] i; C)= (B [] C) [] ; C [M84] R. Milner, Lectures on a Calculus for Communicating Systems, in International Summer School Control Flow and Data Flow: Concepts of Distributed Programming, Munich, Germany, July 31-August 12, [HM85] M. Hennessy, R. Milner, Algebraic Laws for Nondeterminism and Concurrency, Journal of the ACM, Vol. 32, No. 1, Jan

11 Slide 11 B i B i B c (a5) B i C c C B C (a6) Esercizio: Dimostrare la legge (a7): a ; i; B = a ; B a; i; B = a; (B [] i; B)[a5] = a; (B [] B) [] a; B[a6] = a; B [] a; B[a3] = a; B[a3]

12 Slide 12 Esercizio di verifica di equivalenza Max3[in1, in2, in3, out] := in1; (in2; in3; out; stop [] in3; in2; out; stop ) [] in2;(in1; in3; out; stop [] in3; in1; out; stop ) [] in3;(in1; in2; stop [] in2; in1; stop ) Max3-composto[in1, in2, in3, out] := hide mid in Max2[in1; in2; mid] |[mid]| Max2[in3; mid; out] where Max2[in1; in2; out] := in1; in2; out [] in2; in1; out Per verificare Max3 Max3-composto: 1. Costruire i due alberi T3 e T3-composto 2. Collassare 6 sottoalberi di T3-composto usando (a7) 3. Collassare 2 nuovi sottoalberi, usando (a5) 4. Collassare 2 nuovi sottoalberi, usando (a7), ottenendo T3. Max3 in1 in2in3 out in1 in2in3 out Max2 mid

13 Slide Dimostrazione di correttezza di programmi u La dimostrazione formale di correttezza di programmi si basa sullutilizzo di una logica per esprimere proprietà dei programmi, e di assiomi e regole per dimostrarle. u McCarthy (1963) modella i programmi come funzioni ricorsive (esempio: definizione di append(list1, list2)), e ne dimostra proprietà per induzione u Floyd (1967) definisce una logica per programmi imperativi espressi come flowchart. Associa asserzioni logiche (tags) agli archi, che devono essere vere ogni volta che il controllo li attraversa. Un tagged flowchart è dimostrato corretto quando, individualmente, ogni componente è corretta rispetto ai suoi input/output tags. u Hoare (1969) raffina la logica di Floyd, trattando programmi imperativi in forma algebrica

14 Slide 14 u Specifica logica (di una proprietà) del programma P u Pre e Post sono formule logiche del primo ordine, in cui le variabili di input/output appaiono libere {Pre (i1, i2, …, in) } P {Post (o1, o2, …, om, i1, i2, …, in) }

15 Slide 15 Esempi di specifica logica di programmi { z (i1 = z*i2)} P {o1 = i1 / i2} {i1 > i2} P {i1 = i2*o1 + o2 /\ o2 > 0 /\ o2 < i2} {true} P {(o= i1 \/ o = i2) /\ o > i1 /\ o > i2} {i1 > 0 /\ i2 > 0} P {( z1, z2 (i1 = o * z1 /\ i2 = o * z2)) /\ ( h ( z1, z2 (i1 = h * z1 /\ i2 = h * z2) /\ h > o))}

16 Slide 16 Esempio di verifica di programma - esposizione informale u Programma e proprietà u {true} u Begin read (a); read (b); x := a + b; write (x) u end u {o = i1 + i2} u Dimostrazione u o = i1 + i2 vale dopo write(x) sse immediatamente prima vale x = i1 + i2. u Ma lassegnamento x := a+b scrive a+b in x, quindi x = i1 + i2 vale subito dopo lassegn. sse a+b = i1+i2 vale subito prima. u Poiché read(a) e read(b) danno ad a e b i valori dei due input i1 e i2, a+b = i1+i2 deve valere prima dellassegnamento []

17 Slide 17 Le regole della logica di Hoare Applicabili a un linguaggio di programmazione con i costrutti: - x := exp (assegnamento) - begin a1; a2; …; an end - if p then a1 else a2 - while p do a p p, {p}a{q}, q q {p}a{q} {p[exp/x]} x := exp {p(x)} {p}a1{q}, {q}a2{r} {p}a1;a2{r} {p /\ r}a1{q}, {p /\ ¬r}a2{q} {p} if r then a1 else a2 {q} {p /\ q}a{p} {p} while q do a {p /\ ¬q} (NB: le graffe sono usate in modo inverso rispetto a [GJM91]

18 Slide 18 Esempio di verifica: fattoriale di y u Programma: A: x:=1; B B: while y>0 do C C: x:=y*x; y:=y-1 u i) y>0 /\ x*y!=n! x:=y*x y>0 /\ x*(y-1)!= n! first: y>0 /\ x*y! = n! ==> y>0 /\ (y*x)*(y-1)! = n! then: y>0 /\ (y*x)*(y-1)! = n! x:=y*x y>0 /\ x*(y-1)!= n! [rule 2, substituting x for y*x] u ii) y>0 /\ x*(y-1)!= n! y:=y-1 y>0 /\ x*y!= n! first: y>0 /\ x*(y-1)! = n! ==> (y-1) > 0 /\ x*(y-1)! = n! then: (y-1) > 0 /\ x*(y-1)! = n! y:=y-1 y>0 /\ x*y!= n! [rule 2, substituting y for y-1] u (iii) y>0 /\ x*y!=n! C y>0 /\ x*y!= n![rule 3, with (i) and (ii)]

19 Slide 19 u (Programma: A: x:=1; B B: while y>0 do C C: x:=y*x; y:=y-1) u (iii) y>0 /\ x*y!=n! C y>0 /\ x*y!= n! u (iv) y>0 /\ y=n /\ x=1 B x= n! y >0 /\ y=n /\ x=1 ==> p(let p = y >0 /\ x*y! = n!) Let q = y > 0then: (iii) becomes: q /\ p C p which yields: p while q do C p /\ ¬q[by rule 5] that is p B p /\ ¬q p /\ ¬q = y >0 /\ x*y! = n! /\ y y=0 /\ x=n! ==> x=n! In conclusion: y >0 /\ y=n /\ x=1 ==> p, p B p /\ ¬q, p /\ ¬q ==> x=n!, thus (iv) [by rule 1] u (v) y>0 /\ y=n x := 1 y>0 /\ y=n /\ x=1 since p x := 1 p /\ x=1 [by rule 2] u (vi) y>0 /\ y=n A x=n! [rule 3 to (v) and (iv)] []

20 Slide Esecuzione simbolica u Una tecnica a metà fra analisi di correttezza (statica) e testing (dinamica) u Si consideri questo programma P, e il suo grafo control-flow annotato 1. x := y + 2; 2. if [x > a] then 3. a := a + 2; else 4.y := x + 3; endif; 5. x := x + a + y x := y + 2 a := a + 2 y := x + 3 x:= x + a + y [x > a] Esecuzione simbolica: si associano valori iniziali simbolici alle variabili di programma (stato simbolico iniziale), poi...: init [Y+2

21 Slide 21 u Lesecuzione simbolica ha prodotto la tripla: [a = A, y = Y+5, x = 2*Y+A+7],stato simbolico finale (SSfin) »(assegnamento di espressioni simboliche, contenenti variabili simboliche (maiuscole), alle variabili di P (minuscole).,execution path »cammino lungo il control flow graph di P [Y+2A] > u La corrispondenza biunivoca fra execution path e path condition cade per i linguaggi nondeterministici

22 Slide 22 u input e output file sono trattati come sequenze (i1, i2,…) e (o1, o2, …) di var. di programma. Inizialmente: i1 = I1, i2 = I2, … o1 = nil, o2 = nil, … u Il primo Read (x) viene interpretato come x := i1, dunque la sua esecuzione simbolica produce: x = ValSimb(i1) = I1 u Il primo Write (E) viene interpretato come o1 := E, dunque la sua esecuzione simbolica produce: o1 = ValSimb(E) (in termini dello stato simbolico corrente) u Quando si incontra nel programma una condizione cond, come in if cond then S1 else S2 endif while cond Loop u … si considera ValSimb(cond): se il risultato è TRUE o FALSE indipendentemente dai valori delle variabili simboliche, si procede secondo il ramo corrispondente se no, si sceglie nondeterministicamente TRUE (risp. FALSE), e si aggiorna la path condition PC: PC := PC /\ ValSimb(cond) (resp. PC := PC /\ ¬ValSimb(cond) )

23 Slide 23 Verifica tramite esecuzione simbolica u In generale, per ogni programma P si hanno molte, o infinite triple u Pprogramma u inp = (inp 1,..., inp n ) tupla di variabili in input per P u I= (I 1,..., I n )una corrispondente tupla di variabili simboliche u out = (out 1,..., out n ) tupla di variabili in output per P u < u Per verificare {Pre(inp)}P{Post(out)} con esecuzione simbolica: u calcolare tutte le triple (SSFin i, ExecPath i, PathCond i (I)). Per ogni i: usare sempre la stessa Path Condition iniziale: Pre(I) assumendo SSFin i = (out 1 = Exp 1 i (I)),..., (out n = Exp n i (I)) e definendo il predicato PE i come: PE i (I) = Post(Exp 1 i (I)/out 1,..., Exp n i (I)/out n ) verificare che PathCond i (I) ==> PE i (I) u (Trattazione semplificata, senza rappresentazione delle variabili interne di P.)

24 Slide 24 Backward symbolic execution (of protocols) [G. Holzmann, PSTV IV, 1985] u E una variante di reachability analysis: dato uno stato finale indesiderabile S x, calcola transizioni a ritroso fino, possibilmente, a S 0 u Il sistema distribuito -- un protocollo -- viene descritto con un linguaggio simile al CSP di Hoare: qname !mnameoutput; appende mess. mname in coda a qname qname ?mnameinput; eseguibile se mess. mname è correntemente in cima a qname (con cancellazione) v1 := v2assegnamento v1 è una var., v2 è una var. o una costante v++incrementa di 1 la variabile v v--decrementa di 1 la variabile v [v1 R v2]condizione, dove R è =,,,, =; eseguibile se i due operandi (var. o costanti) sono in relazione R I do loops (do…od), sono interrotti dal comando break. Skip è il comando vuoto. :: individua scelte non deterministiche

25 Slide 25 Esempio - Protocollo con memoria condivisa (M, N)

26 Slide 26 u Due processi A e B condividono le code A (verso A) e B (verso B). u Il processo A si rifornisce dalla coda TOB di messaggi che vorrebbe mandare al processo B attraverso la coda B. B si comporta simmetricamente. u La variabile condivisa N è incrementata dal processo A quando un messaggio è appeso alla coda B, ed è decrementata dal processo B quando un messaggio viene cancellato. u Simmetricamente, la variabile condivisa M è incrementata dal processo B quando un messaggio è appeso alla coda A (verso A), ed è decrementata dal processo A quando un messaggio viene cancellato. u Il protocollo forza ciascun processo a ritardare il trasferimento di messaggi verso laltro quando le code sono sature (2 messaggi)

27 Slide 27 u Vogliamo verificare se dallo stato globale iniziale S1: N = 0, M = 0 TOB = (msg, msg), TOA = (msg, msg) A = ( ),B = ( ) u...si puo arrivare allo stato di deadlock S2: N = 2, M = 2 TOB = ( ), TOA = ( ) A = (msg, msg ),B = (msg, msg) u Anziché esplorare tutti i cammini da S1 fino a trovare eventualmente S2, si puo partire da S2 e vedere se S1 è raggiungibile a ritroso. u Inoltre, la esecuzione a ritroso (inversa) della specifica originale equivale a una esecuzione diretta della specifica inversa così costruita:

28 Slide 28 u Scambiare send con receive (? con !) u Scambiare incrementi con decrementi(++ con --) u Invertire il flusso di controllo u Scambiare condizioni con assegnamenti (= con :=) ma usando anche assegnamenti con range di valori (tipico della esecuzione simbolica): CondizioneAssegnamento [N > 5] ==> N := (>5) [N 2] ==> N := 2 u La specifica originale del processo A è convertita in una tabella a stati, che viene invertita ed eseguita in maniera diretta, a partire dallo stato S2.

29 Slide 29 La specifica originale del processo A è convertita nella tabella a stati: La specifica inversa è rappresentata da questa tabella; la sottolineatura distingue i nuovi elementi dai vecchi

30 Slide 30 u Effettivamente si scopre che, attraverso un doppio ciclo nel grafo degli stati globali, il deadlock è raggiungibile. u La tecnica di esplorazione viene detta simbolica perché viene concettualmente esplorato il programma, visto come lista di statements lo stato è la posizione nel programma, ma puo essere parzialmente identificato anche da predicati sui valori di alcune variabili (come M ed N), che ne sfuocano la rappresentazione. u Sfortunatamente la esecuzione inversa non è sempre vantaggiosa rispetto a quella diretta [cfr. Holzmann 85] u Un piu recente approccio alla interpretazione simbolica a ritroso, chiamato Compositional backward technique, è descritto in [Staunstrup+, IEEE Computer, Maggio 2000]


Scaricare ppt "Slide 1 [GJM91, Cap. 6] [BB87] [P93] Appunti u 1. Verifica di equivalenze per algebre di processo u 2. Dimostrazione di correttezza di programmi u 3. Esecuzione."

Presentazioni simili


Annunci Google