Lez. 21 Universita' di Ferrara Facolta' di Scienze Matematiche, Fisiche e Naturali Laurea Specialistica in Informatica Algoritmi Avanzati Semantica assiomatica

Lez. 2 1

Universita' di FerraraFacolta' di Scienze Matematiche, Fisiche e Naturali

Laurea Specialistica in Informatica

Algoritmi Avanzati

Semantica assiomatica.

Analisi degli algoritmi:

correttezza e terminazione.

• Vedi: N. Wirth, Principi di programmazione strutturata, ISEDI

Copyright © 2006-2009 by Claudio Salati.

2

An axiomatic basis for computer programming

• C.A.R. Hoare• Communications of the ACM, Vol. 12, No. 10, Oct. 1969

• Computer programming is an exact science in that

• all the properties of a program and

• all the consequences of executing it in any given environment

can, in principle, be found out

• from the text of the program itself

• by means of purely deductive reasoning

• Vedi Ludwig Wittgenstein, Tractatus logico-philosophicus, Einaudi, punto 6.2.4. Gia' citato.

3

TERMINOLOGIA• Azione: evento che si compie in un intervallo di tempo finito e che

produce un effetto previsto e ben definito:

il significato di ogni azione deve essere ben definito

• Effetto: cambiamento dello stato di un oggetto (del processo)

• Processo sequenziale: azione complessa, scomponibile in azioni piu' semplici, eseguite una dopo l'altra in un ordine determinato

• Programma: descrizione di un processo tramite un linguaggio formale che permette di descrivere azioni e sequenze di azioni tramite istruzioni

• Oggetto: e' una entita' descritta tramite variabili.

Lo stato di un oggetto e' definito dall'insieme dei valori assunti dalle variabili che lo descrivono

• Lo stato di un processo e' dato dall prossima istruzione da eseguire + lo stato di tutti gli oggetti del programma in quel momento

• Assegnamento: e' l'azione fondamentale di un processo sequenziale e consiste nell'attribuire un valore ad una variabile

4

TERMINOLOGIA

• i termini: AZIONE e PROCESSO denotano attivita`, fenomeni dinamici

• i termini: ISTRUZIONE e PROGRAMMA denotano descrizioni, entita` statiche

• un PROCESSO deriva dalla ESECUZIONE di un PROGRAMMA da parte di un processore capace di interpretarne le ISTRUZIONI (scritte in un certo linguaggio), partendo da un insieme di OGGETTI/VARIABILI dato (variabili con un valore iniziale assegnato a priori)

• AD UN PROGRAMMA POSSONO CORRISPONDERE PROCESSI DIVERSI IN CORRISPONDENZA A DATI DI INGRESSO DIVERSI

• TUTTI I PROCESSI CORRISPONDENTI AD UN PROGRAMMA SEGUONO LA STESSA REGOLA DI COMPORTAMENTO: L'ALGORITMO DESCRITTO DAL PROGRAMMA(ma la sequenza di azioni eseguita nei diversi processi puo` differire)

5

SEQUENZIALITA'

• Si suppone che la SEQUENZIALITA' in un programma sia SEMPRE BEN DEFINITA

e.g. x = x + y + z

• significa necessariamente x = ((x + y) + z) o no?

• e.g. puo` significare anche x = (x + (y + z)) ?

• In matematica non c'e' differenza tra le due cose (associativita' dell'operatore +), ma in informatica si' (si parla di associativita' a sinistra o a destra)

N.B.: l'ordine di valutazione degli operandi di un operatore in una espressione e' di norma non definito dai linguaggi di programmazione perche' un programma sia considerato corretto, questo

ordine deve essere irrilevante possiamo quindi assumere un ordine di valutazione da

sinistra a destra

6

Test di un processo sequenziale

• Verifico dopo ciascuna azione che lo stato del processo sia quello desiderato

• Verifico dopo ciascuna azione

• Quale e’ la prossima istruzione da eseguire

• Che il valore delle variabili del programma sia quello desiderato

• Il valore delle variabili del programma e’ quello desiderato se tra i valori delle variabili stesse sussistono certe proprieta’!

7

TESTING VS. VERIFICA

• TEST (EMPIRICO) DI UN PROCESSO vs.VERIFICA FORMALE DI UN PROGRAMMA/ALGORITMO

• TEST EMPIRICO ESAUSTIVO DI TUTTI I PROCESSI VERIFICA FORMALE DEL PROGRAMMA (e della traduzione/interpretazione!) MA E' IMPOSSIBILE, RICHIEDE TROPPO (potenzialmente

) TEMPO!

• N. Wirth: "L'ESAME DI UN PROGRAMMA MEDIANTE TEST EMPIRICO PUO', AL PIU', RILEVARE LA PRESENZA DI ERRORI, MA NON PUO' GARANTIRE L'ASSENZA DI ERRORI, CIOE' LA CORRETTEZZA DEL PROGRAMMA"

• DA CIO' LA NECESSITA' DELLA VERIFICA FORMALE• Ma questa e’ davvero possibile? • Ci sono persino dei limiti teorici, e.g. teorema di Rice!• E in pratica? Con che strumenti?

8

TESTING VS. VERIFICA

• Chi potrebbe mai pensare di effettuare il test empirico del fatto che per ogni triangolo rettangolo l'area del quadrato costruito sull'ipotenusa e' uguale alla somma delle aree dei quadrati costruiti sui cateti?

Si dimostra la verita' del teorema.

Si dimostra che la proprieta’ vale per tutti i triangoli rettangoli, e poi la si applica a ciascuno di essi.

• Lo stesso e' per un programma:

Si dimostra la correttezza del programma, cioe'

Si dimostra che e' vero che il programma trasforma un qualunque insieme I di dati in ingresso che hanno la proprieta' P (I) in un insieme di risultati O che hanno la proprieta' C (O).

Quindi si applica questa proprieta’ a ciascun insieme I di dati di ingresso che ci interessa.

9

TESTING VS. VERIFICA: anticipo delle conclusioni

• LA VERIFICA FORMALE DI UN PROGRAMMA E' COSI' DIFFICILE (PER IL MOMENTO) CHE LA COSA MIGLIORE E' SCRIVERE (SOLO) PROGRAMMI CORRETTI

• E' quindi necessario/conveniente utilizzare tecniche di progettazione che garantiscano che il programma che si scrive sia corretto.

• Come?

• se esistono delle tecniche che ci consentono di ragionare su un programma gia' scritto per determinarne le proprieta‘ (in particolare, correttezza e terminazione),

• potremmo adattare queste stesse tecniche e utilizzarle per scrivere dei programmi che abbiano la proprieta' di essere corretti!

10

VERIFICA• La verifica di un programma si fa' come un caso di test, pero':

• si fa' a mano (per il momento, salvo sviluppi CASE)• deve riguardare tutti i possibili processi derivabili dall'esecuzione

del programma• pertanto quando si parla delle proprieta' delle variabili (degli

oggetti) in un punto del programma ci si deve riferire a proprieta' che sono valide sempre in quel punto del programma, comunque quel punto sia stato raggiunto (e, in particolare, qualunque fosse stato l’insieme dei dati di ingresso per il programma).

• "Si annotano, prima e dopo ogni istruzione, le relazioni significative fra i valori delle variabili, valide in generale."

• "Valida in generale" significa: valida ogniqualvolta un (qualsiasi) processo (derivato dall'esecuzione del programma) raggiunge il punto di annotazione, indipendentemente dalle azioni eseguite precedentemente.

• Si verifica che ogni azione sia tale da trasformare variabili che hanno le proprieta' che valgono prima di lei, in variabili che hanno le proprieta' che si vogliono valere dopo di lei.

11

ASSERZIONI

• Asserzione: espressione delle proprieta' che hanno le variabili di un programma in un punto del suo testo.

Tutte le volte che un qualunque processo di esecuzione del programma si trova a passare per quel punto (indipendentemente da come lo ha raggiunto) le variabili hanno (devono avere) le proprieta' indicate nell'asserzione.

• Prima e dopo una azione/istruzione definiamo due asserzioni, una premessa (P ), e una conseguenza (C ).

• L'effetto di una azione (esecuzione dell'istruzione) e' descrivibile come differenza tra la sua premessa e la sua conseguenza.

• Anche l'effetto di un processo sequenziale (esecuzione del programma) e' descrivibile come differenza tra la sua premessa e la sua conseguenza!

12

ASSERZIONI

… tutte le volte che un qualunque processo di esecuzione del programma si trova a passare per quel punto ...

• All'inizio di una funzione

• In tutti i punti di ritorno di una funzione(la stessa asserzione deve valere in tutti questi punti)

• Dopo un'istruzione if-then o if-then-else, indipendentemente dal fatto che si sia percorso un ramo o l'altro dell'istruzione if

• All'inizio di un ciclo, indipendentemente dal numero di iterazioni (0, 1, …, n) eseguite sul ciclo.

• Dopo un ciclo, indipendentemente dal numero di iterazioni (0, 1, …, n) eseguite sul ciclo.

13

ASSERZIONI

• La semantica di una azione (processo sequenziale) deve essere tale da garantire che "condizione sufficiente perche' lo stato del programma goda delle proprieta' C dopo l'esecuzione dell'azione (processo sequenziale) e' che esso goda delle proprieta' P prima dell'azione (processo sequenziale)“

• La semantica di una istruzione/azione (processo sequenziale) e’ descrivibile come differenza tra la premessa P e la conseguenza C dell’istruzione/azione

istruzione

Premessa P

Conseguenza C

14

ALGORITMO DI EUCLIDE a

// PER IL CALCOLO DEL MCD DI DUE NUMERI

// NATURALI > 0

// I = {i1, i2}

// P = {ikN, ik>0 : k{1, 2}}

// O = {gcd},

// C = {gcdN, gcd=MCD(i1, i2)}

unsigned euclide (unsigned i1, 01

unsigned i2) { 02

assert((i1>0) && (i2>0)); unsigned r, gcd; 03

unsigned k1 = i1; 04

unsigned k2 = i2; 05

assert((i1>0) && (i2>0));

assert((k1>0) && (k2>0));

15

ALGORITMO DI EUCLIDE b

if (k2>k1) { r = k1; k1 = k2; k2 = r; } 06

assert((k1>=k2) && (k2>0)); r = k1 % k2; 07

// 0<k2; 0r<k2k1; nN k1 = n*k2 + r; // insieme dei divisori comuni di i1 e i2 // = insieme dei divisori comuni di k1 e k2 while (r!=0) { 08

k1 = k2; 09

k2 = r; 10

r = k1 % k2; 11

} 12

// k2=MCD(i1, i2) gcd = k2; 13

return(gcd); 14

} 15

16

PROGETTAZIONE

• Progettare un programma equivale a descrivere un insieme di azioni/istruzioni che, eseguite sequenzialmente su oggetti (dati in ingresso) per i quali vale un certo insieme di proprieta' P, portano a rendere valido un altro, desiderato, insieme di proprieta' C per i risultati in uscita.

• La regola di comportamento descritta dal programma deve trasformare tutti gli insiemi di dati in ingresso per i quali vale P in risultati in uscita per i quali vale C.

• Per progettare una azione e' necessario conoscerne la premessa (le assunzioni che e’ legittimo fare sui dati in ingresso) e la conseguenza desiderata.

• Per progettare una azione e' necessario conoscere il significato (la semantica) delle istruzioni che la descrivono.

17

PROGETTAZIONE

• Se un'azione complessa e' scomponibile (deve essere scomposta) in azioni piu' semplici, per progettare ciascuna di tali sub-azioni e' necessario conoscerne la premessa e la conseguenza:

• la premessa della prima sub-azione coincide con la premessa dell'azione.

• la conseguenza dell'ultima sub-azione coincide con la conseguenza dell'azione.

• N.B.: la premessa dell'ultima sub-azione coincide (circa!) con la conseguenza della prima sub-azione!

IP C

I1P S

I2C

18

Semantica Assiomatica

• Tramite assiomi definisco il significato delle istruzioni fondamentali (semplici e composte) del linguaggio di programmazione

• Per ogni istruzione indico quale rapporto esiste tra la sua premessa e la sua conclusione

• Il rapporto tra premessa e conclusione e’ specificato in termini di relazioni che legano il testo della premessa e il testo della conclusione

• Dato il significato di ciascuna istruzione e’ possibile derivare il significato di qualunque programma scritto nel linguaggio di programmazione

19

SEMANTICA ASSIOMATICA: ASSEGNAMENTO

Da C.A.R. Hoare, articolo citato:

Consider the assignment statement:

x = f;where

x is an identifier for a simple variable;

f is an expression of a programming language without side effects, but possibly containing x.

Any assertion C(x) which is to be true of (the value of) x after the assignment is made must also have been true of (the value of) the expression f, taken before the assignment is made, i.e. with the old value of x.

Thus if C(x) is to be true after the assignment, then C(f) must be true before the assignment.

20

SEMANTICA ASSIOMATICA: ASSEGNAMENTO


Axiom of Assignment ├ C0 { x = f; } C

where

x is an identifier for a simple variable;

f is an expression ;

C0 is obtained from C by substituting f for all occurrences of x.

This pattern is described in purely syntactic terms, and it is easy to check whether any finite text conforms to the pattern.

21

SEMANTICA ASSIOMATICA: ASSEGNAMENTON.B.:

• L’Assioma dell’Assegnamento non consente di derivare (immediatamente) C da C0 ma solo C0 da C.

• Cioe’, ci consente solo di sapere cosa deve essere vero prima dell’assegnamento (C0) affinche’ dopo l’assegnamento sia vera la conseguenza desiderata (C).

• Non ci consente invece di sapere direttamente che cosa sara’ vero dopo l’assegnamento (C) sapendo quel che e’ effettivamente vero prima (P).

• Come posso fare quindi a sapere se una certa premessa P mi garantisce una certa conseguenza C?

In base al fatto che sia o no vero che P C0:

Se P C0 allora ├ P { x=f; } C, altrimenti no!

22

SEMANTICA ASSIOMATICA: esempio

z = x + y;

C = { z == 10 }

C0 = { (x+y) == 10 }

i = i + 1;

C0 = { i < N }

C = { i <= N }

Infatti: C0 = { (i+1) <= N }

cioe': C0 = { i <= N-1 }

cioe': C0 = { i < N }

Perche’ sia vero C dopo

l’assegnamento deve

essere vero C0 prima

dell’assegnamento.

C0 non e’ la premessa P

dell’assegnamento ma

deve essere implicata da

P affinche’

l’assegnamento porti alla

conseguenza C

desiderata.

23

SEMANTICA ASSIOMATICA: esempio

z = x + y;

P = { x <= 0; y <= 0 }

C0 = { (x+y) <= 0 }

C = { z <= 0 }

Perche’ sia vero C dopo

l’assegnamento deve

essere vero C0 prima

dell’assegnamento.

La premessa P

dell’assegnamento

implica C0, quindi

l’assegnamento porta

alla conseguenza C

desiderata.

24

SEMANTICA ASSIOMATICA: regole di implicazione


Rules of Consequence

If ├ P { Q; } R and ├ R S then ├ P { Q; } S

If ├ P { Q; } R and ├ S P then ├ S { Q; } R

i = i + 1;

S = { i < 0 }

P = { i <= 0 }

R = { i <= 1 }

Infatti:

• da R discende P = { i < 1 }

• e S P

25

SEMANTICA ASSIOMATICA: Composizione


A program generally consists of a sequence of statements which are executed one after another:

{ Q1; Q2; }

The inference rule associated with composition states that if the proven result of the first part of a program is identical with the precondition under which the second part of the program produces its intended result, then the whole program will produce the intended result, provided that the precondition of the first part is satisfied.

Rule of Composition

If ├ P { Q1; } R1 and ├ R1 { Q2; } R then ├ P { Q1; Q2; } R

26

SEMANTICA ASSIOMATICA: ComposizioneSe

e

e R1.1 R1.2

allora

Q1;P R1.1

Q2;R1.2 R

Q1; Q2;P R

Esempio:

// x<=0; y<=0 (dato)

z = x + y;

// z<=0

z = z - 1;

// z < 0

N.B.: in realta' quest'esempio illustra sia la Composizione di istruzioni che le Rules of Consequence

27

SEMANTICA ASSIOMATICA: Iterazione


The essential feature of a stored program computer is the ability to execute some portion of a program (S) repeatedly until a condition (B) goes false.

while (B) S;

Suppose P to be an assertion which is always true on completion of S, provided that it is also true on initiation.

Then obviously P will still be true after any number of iterations of the statement S (even no iterations).

Furthermore, it is known that the controlling condition B is false when the iteration finally terminates.

A slightly more powerful formulation is possible in light of the fact that B may be assumed to be true on initiation of S.

28



Rule of Iteration

If ├ P B { S; } P then ├ P { while (B) S; } B P

P e' chiamato invariante del ciclo perche' deve essere vero ad ogni iterazione.

• Quello che fa un ciclo e' rendere falsa B pur continuando a mantenere vera P.

• P deve essere vera fino da prima dell'inizio del ciclo!

• E' B che non necessariamente e' falsa fin dall'inizio!

29


// P

while ( B ) {

// P B S;

// P

}

// P B

N.B.: assumendo ├ P B { S; } P

B

S

PP

P

P B

P B

FALSE

TRUE

30

Iterazione: esempio

int findMinEl(unsigned int N, double v[]) { 1

// P = { N1, double v[N] } int i = 0; int iMin = 0; 2

// P1 = { ..., 0iMini, 0iN-1, j=0..i: v[j]v[iMin] } while ( i < N-1 ) { 3

i += 1; 4

if ( v[i] < v[iMin] ) iMin = i; 5

} 6

// C = { ..., 0iMinN-1, j=0..N-1: v[j]v[iMin] } return iMin; 7

} 8

• Alla fine del ciclo iMin e’ l’indice dell’elemento minimo del vettore v.

• Ma anche all’inizio del ciclo iMin e’ l’indice dell’elemento minimo di quella parte del vettore v che ho gia’ esaminato!

• Quello che cambia tra l’inizio e la fine e’ il valore di verita’ della condizione di controllo del ciclo: nel vettore v ci sono ancora elementi non esaminati?

31

SEMANTICA ASSIOMATICA: Invarianti

In realta' ogni asserzione e' un invariante.

• Sono in particolare invarianti la premessa e la conseguenza di una funzione:

• un chiamante deve garantire che la premessa della funzione chiamata sia vera al momento della chiamata;

• il chiamato garantisce quindi la veridicita' della propria conseguenza al momento del ritorno (di qualunque statement return).

• E' questo il contratto che lega una funzione e i suoi clienti!

contratto chiamante/chiamato

aspetti sintattici: prototipo della funzione

aspetti semantici: prototipo della funzione + (premessa e conseguenza)

32

SEMANTICA ASSIOMATICA: Invarianti

N. Wirth, Principi di programmazione strutturata, ISEDI :

L'indicazione degli invarianti ciclici rilevanti di ogni loop e' la base di ogni buona documentazione.

C. Salati, Algoritmi Avanzati, Lez. 2, pag. 32:

L'indicazione della premessa e della conseguenza di ogni funzione (cioe' del suo del contratto chiamante-chiamato) e' parte essenziale di ogni buona documentazione.

Corollario:

poiche' un programma non e' nient'altro che la sua funzione main(), quanto detto prima si applica in particolare anche ad un programma nel suo complesso.

33

SEMANTICA ASSIOMATICA: cicli

COSTRUZIONE/VERIFICA di un ciclo WHILE:

1. SI SCEGLIE UN PUNTO DI TAGLIO z

2. SI FISSA LA PREMESSA P CHE DEVE VALERE NEL PUNTO DI TAGLIO z+

3. APPLICANDO LE REGOLE PRECEDENTI E SEGUENDO IL CICLO SI DERIVA LA CONSEGUENZA C CHE DEVE VALERE NEL PUNTO DI TAGLIO z-

4. PERCHE' LA RICHIUSURA DEL CICLO SIA LEGALE DEVE RISULTARE ├ C P

• IL PUNTO DI TAGLIO E' SCELTO CONVENIENTEMENTE A MONTE DEL TEST B, COSI' CHE

– P e` la premessa del WHILE nel suo complesso

– P B e` la conseguenza del WHILE nel suo complesso

• l'idea e` che all'inizio P sia vera in forma banale e che ogni iterazione ne aumenti la significativita`

• garantire la terminazione significa arrivare a falsificare B

34

Confluenze e Ramificazioni

In un ciclo while sono presenti:

• un punto di ramificazione del programma;

• un punto di confluenza di due rami del programma.

Basandosi sulle regole di implicazione si e' assunto che:

• quando piu' cammini del programma si congiungono nel punto che precede una istruzione R, la premessa P(R) deve essere logicamente implicata da ciascuna delle conseguenze C(S1), …, C(Sn) di tutte le istruzioni S1, …, Sn che confluiscono in R.

• un punto di ramificazione di un programma e' sempre associato ad una espressione booleana B. Se vale la premessa P(B), allora

• sul ramo associato al valore vero di B vale la conseguenza BP

• sul ramo associato al valore falso di B vale la conseguenza BP

35

SEMANTICA ASSIOMATICA: Istruzioni condizionali

Le regole di confluenza e ramificazione ci consentono di trattare anche gli statement if-then e if-then-else

Da N. Wirth, Principi di programmazione strutturata, ISEDI

Rule of statement if-then

If ├ P B { S; } C and ├ P B C

then ├ P { if (B) S; } C

Rule of statement if-then-else

If ├ P B { S1; } C and ├ P B { S2; } C

then ├ P { if (B) S1; else S2; } C

36


// P

if ( B ) {

// P B S;

// C

}

// C

N.B.: assumendo ├ P B { S; } C and ├ P B C

B

S

P

C

P BP B

FALSE

TRUE

C

37


// P

if( B ) {

// P B S1;

// C

} else {

// P B S2;

// C

}

// C

N.B.: assumendo ├ P B { S1; } C and ├ P B { S2; } C

B

S2

P

CC

P BP BFALSETRUE

S1

C

38


Esempio:

// 0 <= x; 0 <= y

if (x >= y) {

// 0 <= x; 0 <= y; x >= y

x = y;

// 0 <= x; 0 <= y; x == y

} // else 0 <= x; 0 <= y; x < y

// 0 <= x <= y; 0 <= y

39


Esempio:

// P = { N1, int v[N], 0iMin<i,

// 0<iN-1, j=0..i-1: v[j]v[iMin]}

if (v[i] < v[iMin]) {

// P’={ N1, int v[N], 0iMin<i,

// 0<iN-1, j=0..i-1: v[j]v[iMin],

// v[i]<v[iMin]}

iMin = i;

// C’ = { N1, int v[N], 0iMini,

// 0iN-1, j=0..i: v[j]v[iMin] }

}

// C = { N1, int v[N], 0iMini,

// 0iN-1, j=0..i: v[j]v[iMin] }

40

TEOREMA DI BOEHM-JACOPINI

• QUALSIASI PROGRAMMA DESCRITTO TRAMITE FLOW-CHART PUO' ESSERE TRASFORMATO IN UN ALTRO PROGRAMMA NEL QUALE LA FLOW-CHART CONTIENE SOLO LE SEGUENTI FORME DI COMPOSIZIONE:

• SEQUENZA,

• SELEZIONE,

• ITERAZIONE

AGGIUNGENDO SOLO STATEMENT DI ASSEGNAMENTO, VARIABILI AUSILIARIE, E TEST SU TALI VARIABILI

• SONO STATI DATI MOLTI ALGORITMI DI TRASFORMAZIONE SEMPRE PIU' "STRINGENTI", CIOE' TALI DA MANTENERE IL FLUSSO DI CONTROLLO "LOGICO" DELLA FLOW-CHART ORIGINALE

41

TEOREMA DI BOEHM-JACOPINI: esercizio

• esercizio:

SCHEMATIZZARE UN ALGORITMO (banale) BASATO SU UNA SOLA VARIABILE AUSILIARIA CHE TRASFORMI QUALUNQUE FLOW-CHART IN UNA FLOW-CHART BASATA SOLO SULLE REGOLE DI COMPOSIZIONE

• SEQUENZA,

• SELEZIONE,

• ITERAZIONE

(si pensi a come funziona un calcolatore, a numerare i box della flow-chart, ...)

42

TEOREMA DI BOEHM-JACOPINI: conseguenza

• Poiche' abbiamo definito la semantica

cioe' la regola di trasformazione premessa / conseguenza

di tutte le forme di composizione di statement necessarie per esprimere qualunque algoritmo secondo il teorema di Boehm-Jacopini,

abbiamo in linea di principio tutti gli strumenti necessari ad analizzare e verificare la correttezza di qualunque algoritmo/programma

• Abbiamo anche gli strumenti necessari a progettare (esprimere) correttamente qualunque algoritmo/programma!

43

ESEMPIO DI VERIFICA DI CORRETTEZZA

int moltiplica (int x, int y) {

int z = 0;

int u = x;

while (u>0) {

z = z + y; u = u - 1;

}

return (z);

}

• Cosa significa dire che moltiplica() e' corretta?

• Bisogna per prima cosa indicarne premessa e conseguenza!

44


int moltiplica (int x, int y) {

assert (x>=0 && y>=0); // P

int z = 0;

int u = x;

while (u>0) {

z = z + y; u = u - 1;

}

assert((x>=0 && y>=0) && z==x*y); // C

return (z);

}

• moltiplica() e' corretta se “condizione sufficiente perche' z abbia la proprieta' indicata nell'assert() finale e' che x e y abbiano la proprieta' indicata nell'assert() iniziale”.

45


int moltiplica (int x, int y) { assert (x>=0 && y>=0 && x*y==x*y); // P int z = 0; int u = x; assert((x>=0 && y>=0) && (u>=0 && z+u*y==x*y)); // A1 while (u>0) { assert((x>=0 && y>=0) && (u>0 && z+u*y==x*y)); // A2 z = z + y; u = u - 1; assert((x>=0 && y>=0) && (u>=0 && z+u*y==x*y)); // A3 } // assert((x>=0 && y>=0) && // (u==0 && z+u*y==x*y)); // A4 assert((x>=0 && y>=0) && z==x*y); // C return (z);}

46

ESEMPIO DI VERIFICA DI CORRETTEZZA - nota 0

Nota che:

• A2 e’ derivata da A1 per il fatto che l’unica cosa che le separa e’ il test (u>0)

• Se A1 e’ verificata, allora e’ verificata anche A2

• A4 deriva da A1 per l’Assioma dell’Iterazione (a patto che il ciclo sia ben strutturato)

• Se A1 e’ verificata (e il ciclo e’ ben strutturato), allora e’ verificata anche A4

• P e’ (deve essere) garantita dal chiamante, secondo quanto previsto dal contratto chiamante-chiamato

47


assert((x>=0 && y>=0) &&

(u>0 && z+u*y==x*y)); // A2

z = z + y; u = u - 1;

assert((x>=0 && y>=0) &&

(u>=0 && z+u*y==x*y)); // A3

Infatti:

A3 = {x>=0, y>=0, (u>=0, z+u*y==x*y)}

sostituendo nel testo di A3 (u-1) a u e (z+y) a z si ottiene:

A30 = {x>=0, y>=0, ((u-1)>=0, (z+y)+(u-1)*y==x*y)}

cioe': A30 = {x>=0, y>=0, (u>=1, z+y+u*y-y==x*y)}

cioe': A30 = {x>=0, y>=0, (u>0, z+u*y==x*y)} = A2 (quindi A2A30)

Il corpo del ciclo mantiene l’invariante, cioe’ il ciclo e’ ben strutturato

48


assert (x>=0 && y>=0 && x*y==x*y); // P

int z = 0;

int u = x;

assert((x>=0 && y>=0) &&

(u>=0 && z+u*y==x*y)); // A1

Infatti:

A1 = {(x>=0, y>=0), (u>=0, z+u*y==x*y)}

sostituendo nel testo di A1 x a u e 0 a z si ottiene:

A10 = {x>=0, y>=0, (x>=0, 0+x*y==x*y)}

cioe': A10 = {x>=0, y>=0, x*y==x*y} = P (quindi PA10)

L’inizializzazione del ciclo e’ corretta, in quanto ne rende vero l’invariante

49


assert((x>=0 && y>=0) &&

(u>=0 && z+u*y==x*y)); // A1

while (u>0) {...}

// assert((x>=0 && y>=0) &&

// (u==0 && z+u*y==x*y)); // A4

assert((x>=0 && y>=0) && z==x*y); // C

Infatti:

Applicando la regola dell'iterazione (la cosa e' legittima per quanto dimostrato in "nota 1"), dalla premessa A1 del ciclo,

essendo per la condizione di controllo: B = {u>0},

si ha:

A4 = A1 B = {x>=0, y>=0, (u>=0, z+u*y==x*y), u<=0}

cioe': A4 = {x>=0, y>=0, u==0, z+0*y==x*y}

cioe': A4 = {x>=0, y>=0, u==0, z==x*y} = C

Il ciclo fa quello che vogliamo che faccia

50

CORRETTEZZA E TERMINAZIONE

• Una dimostrazione di correttezza non dimostra che il programma termina.

• Dice solo che, se termina, fornisce il risultato desiderato.

• Se terminasse, nonMoltiplica() calcolerebbe x*y, ma per x>0 non termina!

int nonMoltiplica (int x, int y) { assert (x>=0 && y>=0); int z = 0; int u = x; assert((x>=0 && y>=0) && (u>=0 && z+u*y==x*y)); while (u>0) { assert(x>=0 && y>=0 && u>0 && z+u*y==x*y);

// z = z + y; u = u - 1; assert(x>=0 && y>=0 && u>=0 && z+u*y==x*y); } assert((x>=0 && y>=0) && z==x*y); return (z);}

51

DIMOSTRAZIONE DI TERMINAZIONE

• Come possiamo essere sicuri che moltiplica() termini?

• Perche' ad ogni iterazione u (che e' per ipotesi 0, e che se il corpo del ciclo viene eseguito deve essere strettamente positiva) viene decrementata di 1 (u e' monotona descescente con le iterazioni del ciclo).

• Quando u raggiunge il valore 0, come deve necessariamente succedere, il ciclo termina.

• N.B.: la condizione dello statement while avrebbe potuto essere scritta anche come (u!=0)

• LA TERMINAZIONE DI UN PROGRAMMA E' GARANTITA DALLA TERMINAZIONE DI TUTTI I SUOI CICLI

(E DELLE SUE RICORSIONI!)

• Per garantire la terminazione di ciascun ciclo si generalizza l'argomentazione utilizzata per dimostrare la terminazione del ciclo della funzione moltiplica()

52

TERMINAZIONE DI UN CICLO(o di una ricorsione)

• Consideriamo il ciclo

while ( B ) S;

• Si definisce una grandezza intera N funzione dello stato degli oggetti del programma.

• N e' (deve essere) tale che se B e' vera allora vale N 0.

• Nel processo di esecuzione del ciclo N e' (deve essere) monotona decrescente:

• Dopo ogni iterazione N e' (strettamente) minore di quanto era prima.

• Cioe', l'esecuzione dell'istruzione S provoca una diminuzione del valore di N.

• Quindi ad un certo punto diventera' N < 0: quando cio' succede B deve necessariamente essere falsa.

• Nel caso particolare di moltiplica() e': N = u-1

53

ANALISI DI UN CICLO

• Cosa devo verificare di un ciclo?

while ( B ) S;

1. Che sia inizializzato bene, cioe' che le istruzioni precedenti siano tali da rendere vero l'invariante quando si raggiunge il ciclo.

2. Che il ciclo sia ben strutturato, cioe' che mantenga vero l'invariante ad ogni iterazione.

3. Che il ciclo faccia quello che si desidera, cioe' che la combinazione dell'invariante & della negazione della condizione di controllo implichi la conseguenza desiderata del ciclo.

• Cosa devo dimostrare ancora di un ciclo?

4. Che termini.

54

Esempio: Fattoriale .1

// I = { n }// P = { nI, n>=0 }// O = { fatt },// C = { fattN, fatt=n!}

unsigned fattoriale (unsigned n) { // P = { n >= 0 } unsigned fatt = 1; unsigned t = 0; while (t<n) { fatt = fatt * (t+1); t = t+1; } // C = { fatt = n! } return(fatt);}

55


• Dove devo inserire delle asserzioni?

unsigned fattoriale (unsigned n) { // P = { n >= 0 } unsigned fatt = 1; unsigned t = 0; // I = { invariante del ciclo } while (t<n) { // I' = { invariante del ciclo & t<n } fatt = fatt * (t+1); t = t+1; } // I” = { invariante del ciclo & t>=n } // C = { fatt = n! } return(fatt);}

56


Ricetta:

• Invento un invariante tentativo che descriva la logica del problema (l'asserzione I).

• Verifico se l'asserzione I e' plausibile:

1. e' resa vera dall'inizializzazione del ciclo?

• Verifico se l'asserzione I e' tale da soddisfare la conseguenza desiderata del ciclo:

2. I & la negazione della condizione di controllo (cio' che ho garantito all'uscita dal ciclo) implicano C (cio' che desidero all'uscita dal ciclo)?

• Verifico se il ciclo e' ben strutturato:

3. il corpo del ciclo e' tale da mantenere vero l'invariante del ciclo?

• Verifico che il ciclo termini necessariamente:

4. il corpo del ciclo e' tale da portare a falsificare la condizione di controllo del ciclo?

57

Esempio: Fattoriale .4// I = { n }// P = { nI, n>=0 }// O = { fatt },// C = { fattN, fatt=n!}

unsigned fattoriale (unsigned n) { // P { n >= 0 } unsigned fatt = 1; unsigned t = 0; // I = { t <= n; fatt = t! } // N = n-t-1 while (t<n) { // I' = { t < n; fatt = t! } fatt = fatt * (t+1); t = t+1; // qui deve essere vero I } // { I (t>=n) } C = { fatt = n! } return(fatt);}

Documents

Lez. 21 Universita' di Ferrara Facolta' di Scienze Matematiche, Fisiche e Naturali Laurea Specialistica in Informatica Algoritmi Avanzati Semantica assiomatica