Una procedura di Model Checking in un dominio lineare astratto per la verifica di programmi C con array

Transcript

1 Università degi Studi di Napoi Federico II FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea in Informatica Una procedura di Mode Checking in un dominio ineare astratto per a verifica di programmi C con array Tesi di Laurea di: Dario Dea Monica Matricoa: 961/22 Reatore: Prof. Massimo Benerecetti Correatore: Prof. Giovanni Criscuoo Anno Accademico 2006/2007

2 Ringraziamenti Finamente è finita!!! Dopo 19 unghi brevi anni a scuoa è finita e mi ritrovo ne momento più beo, in cui ricordare e rendere grazie a tutti cooro che in quache modo hanno contribuito o hanno reso più beo i percorso che mi ha condotto fin qui. E beo rendere grazie a chi di dovere perchè è importante far capire che nessuno fa nua da soo, ma un uomo è potentissimo se parte di un ingranaggio di persone che remano tutte nea stessa direzione. Pertanto queste paroe sono rivote a tutti cooro che, anche se non espicitamente menzionati, hanno remato con me, per un breve o ungo periodo. Queste non vogiono essere dee banai paroe di circostanza ma dei sentiti ringraziamenti a persone a cui in un modo o ne atro vogio bene e meritano i mio rispetto e a mia stima. Si sa che spesso è difficie dire dee cose da vivo, magari perchè a vote è difficie ritagiarsi una situazione, un momento adeguato a fare determinate esternazioni, pertanto esse restano soo nee intenzioni, senza mai concretizzarsi. Pertanto approfitto di questo momento di rifessione per dire cose e rendere grazie. Innanzitutto appare indispensabie menzionare e ringraziare gi artefici principai dee mie gioie e soddisfazioni, i miei genitori, che con tanti sacrifici avorano giorno dopo giorno aa costruzione dea mia vita feice. Sacrifici che vengono motipicati nei momenti di bisogno o ne momento di dover accontentare quache mio capriccio, detto tra virgoette perchè acuni capricci non sono veri e propri capricci bensì tappe indispensabii aa formazione sociae e cuturae di un individuo. Per quanto mi riguarda, ho sempre ricevuto i megio sia da mia madre che mi ha sempre dimostrato tutte e attenzioni, a comprensione, affetto e atruismo che soo una mamma può trasmettere, che da mio padre, che mi ha insegnato a vivere e sopravvivere, a rischiare, a non avere paura e a credere in me stesso ameno tanto quanto ui credeva in me. Ritornando ai momenti de bisogno, devo ringraziare una persona che si dimostra sempre preziosa ed impeccabie quando serve. La mia badante 1

3 satuaria e a tempo pieno, mia sorea Tamara, sempre pronta ad assecondare e soddisfare e mie richieste ed esigenze, anche e più stravaganti, e sempre pronta a cogiere e diffondere un momento di aegria. Devo ringraziare poi un atra grottesca figura che utimamente ha preso a ronzarmi attorno, richiedendo attenzioni, energie e tempo ma ripagandoe in maniera subime, contribuendo a migiorare con a sua perenne aegria (tranne quando fa a parte di quea incazzata e rompe e... sinergie) a quaità dea vita di tutte e persone che hanno a fortuna entrarvi in contatto. Si tratta di Immacoata a cui devo moto e a cui va tutta a mia gratitudine e non soo. Ah, dimenticavo... i soggetto presenta anche un insospettabie intraprendenza. Non cambiare, se possibie!!! Porgo i miei ringraziamenti anche a professor Benerecetti (i Bene, per i nemici), che ho imparato ad apprezzare per a sua umanità, prima che per a sua competenza e preparazione. Spesso incompreso (siamo sicuri???) e messo sotto accusa per a sua eccessiva curiosità e magnanimità dae mamme dei aureandi che preferirebbero meno domande per i oro figi in sede di seduta di aurea. Scherzi a parte, porgo i miei più sinceri ringraziamenti per a pazienza ed i tempo (davvero tanto) dedicatomi, sottoineando che per me si è trattato comunque di tempo trascorso piacevomente. Ora viene a parte più difficie... ringraziare una motitudine di gente che merita, sperando di non dimenticare nessuno, anche se conto su fatto che queste persone non sono affatto permaose e di certo non si offenderanno se verranno omesse, ben sapendo che se non vengono menzionate sarà soo perchè si sa che i periodo pre-aurea è carico di impegni e scadenze e pertanto a memoria vien di gran unga imitata (figuriamoci a mia, già abbastanza corta). Innanzitutto vogio ringraziare casa Abate, in particoare Hepettino, Sababano e 3sidente, a cui ospitaità sicura ed incondizionata mi ha reso a vita estremamente più facie. E stato un piacere di pazzi scroccare da voi un etto a due piazze, teefono, internet, eggere insaate aa Evio con TUTTO dentro. E stato beo partecipare a discussioni poitiche, con annessi progetti per un domani migiore, portate avanti fino ae 4 de mattino in condizioni di precaria ucidità. Ma a cosa più bea è che grazie a goffo, e sottoineo ingiusto, soprannome gentimente affibiatomi da fioreino, non ho mai dovuto cucinare nè fare neanche i più piccoo avoro in casa :-). Un grazie, anche se MENO SENTITO, va anche a Sukkiotto e a Ntonio per a oro ospitaità. Si tratta tuttavia di un grazie meno sentito, a costo di sembrare scortese, perchè i due soggetti hanno avuto i coraggio di farmi dormire in pianerottoo, a freddo e a geo di una notte d estate napoetana e soprattutto mi hanno fatto pagare fitto e boette per ben 2 (DUE) mesi e tutto ciò soo perchè Ntonio è più avaro di zio Paperone. P.S.: Vediamo che 2

4 fai mo che hai conosciuto a mia sorea e se e dici ciò che promettevi, ehehe. P.P.S.: ragazzi scherzo ogicamente. Grazie davvero. Come non menzionare imponente Annapaoa (per gi amici Grasso o AnnaProvoa, si resta sempre in campo aimentare e non poteva essere atrimenti per una briante dottoressa aureata con una tesi su McDonad. Aspettiamo tutti di eggere quea su Burger King). Ricordo i giorni feici in cui si scomodava a venire fin ne mio studioo ad insutarmi a domiciio e ricordo con affetto quando non potendoi mangiare perchè perennemente a dieta con scarsissimi (se non inesistenti) risutati, mi portava i geati mentre io ero impegnato a scrivere sta tesi. A ta proposito Annapaoa ti vogio dire una cosa: Ricorda, non sei grassa... sei soo robusta di costituzione... Ah, dimenticavo... ti trovo dimagrita!!!. Un ricordo va anche a bioogi e biooghe, in particoare ad Anna e Vaentina, che venivano gentimente ad importunarmi tra una ezione e atra con i soo scopo... mmm... ora che ci penso venivano senza motivo, CHE VENIVATE A FARE!!!!! Ricorderò con affetto modi e soprattutto uogo de nostro primo incontro. Ma un grazie grande quanto una casa va anche a GAYtano i pisciaiuoo, per a sua ospitaità nea sua beissima casa fatta di etti, anzi materassi, appoggiati su pavimento, ma davvero comodi. Ricorda sempre: LA CAPOLISTA SE NE VA. Se Ligabue cantava Lambrusco e pop-corn, devo ringraziare Eugenietta, inventrice nonchè generosa dispensatrce de famosissimo connubio Levinska e pop-corn, otre che di frasi ad effetto per a mia tesi... Ricorda che sei di VITALE IMPORTANZA per me e non vedo ora in cui potremo dichiarare a mondo i nostro amore... ahia Imma stavo soo scherzando (no Eugenia era tutto vero). Mi sembra di aver finito. Spero di non aver dimenticato nessuno, anche se in reatà ci sono mote atre persone che andrebbero menzionate come Rosaria, per a sua attività di verifica dea tesi oppure Roberta, che mi ha ospitato a casina sua, come Aessandro Siani, atro fornitore di giacigi temporanei, che mi ha anche riveato esistenza de TAVOLO DA PING-PONG DELL ULTIMO PIANO, teatro di tante battagie tra me e i Punziano che mi hanno visto sempre perdente o ancora Nicoa e Fuvio con cui ho condiviso i aboratorio e che tavota mi hanno fornito piccoi e preziosi suggerimenti e ancora tante tante atre persone con cui ho condiviso momenti ed emozioni, bee, brutte ma mai insignificanti. A tai persone che per un motivo o per un atro non compaiono qui, un SENTITO GRAZIE, perchè grazie a voi sono cresciuto, ho imparato quacosa daa vostra personaità che vaeva a pena apprezzare e imitare, perchè ognuno ha quacosa da insegnare a quasiasi atra persona su questa terra, a bravura sta ne riuscire a cogiere gi aspetti positivi di ognuno e riuscire a fari propri. Pertanto spero che anche 3

5 io sia riuscito a trasmettere quacosa ad ognuno di voi così che i cammino effettuato insieme non sia stato inutie. Ciao e grazie a tutti. 4

6 Indice Introduzione 7 1 Verifica di software Introduzione aa verifica formae Mode checking simboico Tecniche di astrazione per i software Domini di astrazione Un esempio di esecuzione di Eureka Astrazione Programmi ineari con array generaizzati Espressioni ineari generaizzate con array ed espressioni ineari booeane generaizzate con array Sintassi dei programmi ineari con array generaizzati Rappresentazione tramite CFG Scope dee variabii Semantica di programmi ineari con array Introduzione a astrazione Astrazione sintattica Astrazione semantica Un uteriore beneficio derivante da processo di astrazione Meccanismo di astrazione preesistente in Eureka Anaisi dei imiti de precedente meccanismo di astrazione utiizzato in Eureka Un nuovo meccanismo di astrazione Semantica ineare astratta per programmi ineari con array Astrazione ŵ dea funzione di vautazione concreta w Estensione dea funzione di vautazione astratta ŵ aa funzione ŵ Scope dee variabii astratte Definizione di stato astratto

7 2.5.5 Reazione di transizione astratta e percorsi astratti Funzioni di astrazione α e concretizzazione γ Correttezza de astrazione proposta Teorema di correttezza de astrazione Mode checking Interprocedura Data Fow Anaysis per programmi ineari Path Edge e Summary Edge Mode Checking simboico per programmi ineari Codifica in aritmetica ineare degi statement de programma (α e β) Rappresentazione simboica tramite ADLC Manipoazione degi ADLC Controparte simboica de agorimtmo di Interprocedura Data Fow Anaysis Interprocedura Data Fow Anaysis per astrazioni di programmi ineari con array Path Edge astratti Procedura simboica di mode checking per astrazioni di programmi ineari con array Simuazione e raffinamento de modeo Verifica di fattibiità dea traccia Raffinamento de modeo Meccanismo di raffinamento in Eureka Impementazione Architettura di Eureka Moduo per astrazione Moduo di verifica PPL: The Parma Poyhedra Library Costruzione de ADLC corrispondente aa reazione di transizione e verifica de modeo Simuazione e raffinamento CVC Lite Concusioni 145 Bibiografia 147 6

8 Introduzione I presente avoro di tesi trova a sua coocazione ne ambito dea verifica automatica di software, in particoare esso contribuisce ao sviuppo di Eureka, un too di verifica automatica di sistemi. Mote attività umane traggono benefici in termini di veocità, precisione ed affidabiità da automazione, totae o parziae, dei processi in essi coinvoti. In particoare, attenzione è posta sia ad attività personai, avorative o di svago, sia e soprattutto ad attività di pubbico interesse. Basti pensare a crescente utiizzo di persona computer per e più disparate attività, a automazione di processi produttivi industriai, de sistema bancario, fino ad arrivare a importanza dei cacoatori nea gestione di operazioni spaziai o a utiizzo di strumenti robotici ad ata precisione per i oro impiego in campo medico. Se in acune di tai attività errori di sistemi informatici sono toerati, nea maggior parte dei casi appare evidente che potrebbero avere conseguenze moto spiacevoi e comportare ingenti danni a iveo economico, ma anche in termini di saute o vite umane. Tai sistemi, i cui corretto funzionamento è di vitae importanza, sono definiti safety critica. Fanno parte di questa categoria i software per a gestione di sateiti, i sistemi per i controo de traffico aereo e ferroviario, i database bancari, i sistemi sanitari e e appicazioni utiizzate ne ambito miitare. Attuamente i mezzo di verifica software più diffuso ed utiizzato consiste ne processo di simuazione e test, che prevede esecuzione de software a fronte di determinati input e a verifica che i sistema fornisca e risposte corrette. Sebbene tae tecnica renda possibie individuazione di numerosi bug, è quasi sempre impossibie simuare tutti i comportamenti di un sistema anche moto sempice, pertanto spesso non è in grado di fornire una risposta esaustiva circa assenza di errori. È quindi fondamentae, per i sistemi safety critica, sostituire o affiancare tae meccanismo di verifica con tecniche formai capaci di dare una risposta esaustiva circa a presenza o meno di errori. Esistono, pertanto, numerosi mezzi di verifica formae, tra cui i theorem proving e i mode checking, i quai, attraverso a descrizione formae de 7

9 sistema in esame e dea proprietà che si desidera verificare, permettono, in maniera automatica o semiautomatica, di dimostrare che tutti i comportamenti de sistema verifichino a proprietà desiderata, superando i imiti dee tecniche di testing e simuazione. Ne caso de theorem proving, sia i sistema che e proprietà che si desiderano verificare devono essere prima espressi in una ogica appropriata, poi viene costruita una dimostrazione de fatto che tai proprietà siano derivabii daa descrizione de sistema. Tae approccio è moto potente e fessibie, tanto è vero che può essere appicato a sistemi moto compessi ed anche a stati infiniti, ma difetta nea costruzione dea dimostrazione, che non è facie e spesso viene richiesta interazione da parte de utente, che suggerisce quai passi di prova eseguire, affinché i sistema riesca a portara a termine. I mode checking, invece, prevede sia a descrizione de sistema attraverso un Labeed Transaction System (LTS - sistema a transizioni etichettato) che quea dea proprietà da verificare attraverso una ogica temporae (ad esempio Linear Tempora Logic, LTL, o Computationa Tree Logic, CTL). La procedura di mode checking termina con risposta affermativa quaora i modeo verifichi a proprietà, atrimenti esibisce un controesempio di percorso di esecuzione ammissibie ne sistema, per cui una dee proprietà specificate non è vaida. Un grande imite de mode checking sta ne fatto di dover rappresentare espicitamente tutti gi stati de sistema e ciò impica un carico di memoria che imita a dimensione de sistema de quae si desidera eseguire verifica. Per ovviare tae probema sono state introdotte tecniche per a rappresentazione simboica degi stati, grazie ae quai è stato possibie aumentare i numero degi stessi, estendendo quindi insieme di sistemi per i quai è possibie eseguire verifica. Si para quindi di mode checking simboico, attraverso i quae si sono ottenuti ottimi risutati nea verifica di circuiti eettronici di piccoe e medie dimensioni. I mode checking simboico è comunque appicabie soo a sistemi con un determinato dominio di appicazione, ad esempio programmi booeani oppure programmi ineari. Attuamente non è possibie, ad esempio, eseguire mode checking di programmi con array. Pertanto per a verifica di tae casse di programmi è necessario introdurre una fase preiminare che trasformi i programmi con array in programmi con un dominio più sempice (programmi booeani o programmi ineari). Tae operazione è portata a termine da processo di astrazione. L astrazione è un processo che permette di mappare un sistema in un atro moto più sempice attraverso a riduzione de numero dei suoi stati o attraverso a mappatura de inguaggio de programma originae in un inguaggio che sia più facie da manipoare. Attraverso a costruzione di modei astratti è stato possibie sfruttare tecniche di mode checking anche 8

10 per a verifica di software, dando quindi origine a software mode checking. Affinché a verifica possa terminare con successo è indispensabie trovare i giusto iveo di astrazione. A ta fine si è introdotto i paradigma CEGAR (Counter Exampe Guided Abstraction Refinement) che permette di giungere a giusto iveo di astrazione attraverso una o più iterazioni de cico Astrazione-Verifica-Raffinamento. L approccio è stato seguito con successo nea reaizzazione de too di verifica SLAM di Microsoft che prevede utiizzo de dominio dei programmi booeani come dominio astratto. Nonostante i too fornisca ottimi risutati ne ambito dea verifica di driver, si è mostrato poco efficiente nea verifica di atre tipoogie di software, in particoar modo per programmi in cui a manipoazione dei dati è predominante rispetto a fusso di controo. Si è deciso di progettare e sviuppare un too di verifica che superi i imiti di SLAM ma che ne erediti i pregi. Nasce così i progetto Eureka, voto aa verifica di programmi ineari con array, ovvero programmi nei quai e variabii sono di tipo numerico e ogni espressione è un espressione ineare. Prevede utiizzo dei programmi ineari come dominio astratto e appicazione de paradigma CEGAR per giungere a giusto iveo di astrazione. I dominio astratto sceto ha i vantaggio di essere più vicino ai programmi concreti rispetto a dominio dei programmi booeani. Tae caratteristica dovrebbe ridurre i numero di cici astrazione-raffinamento e quindi migiorare e prestazioni compessive. Inotre i programmi ineari sono più adatti aa rappresentazione di programmi in cui a manipoazione dei dati è predominante. Ne ambito de progetto Eureka i mio contributo è mirato ad una futura estensione de too aa verifica di programmi C con puntatori. Tenendo presente che a memoria di un programma può essere vista come uno sconfinato array, i cui eementi (e varie ocazioni di memoria) sono accessibii tramite i puntatori, un primo e fondamentae passo verso introduzione degi stessi ne processo di verifica di Eureka è queo di riuscire a gestire, in fase di astrazione e raffinamento, i generici eementi di un array. D atronde i inguaggio C tratta in maniera perfettamente anaoga eementi di un array e ocazioni di memoria puntate da puntatori. Nea precedente versione di eureka, un array veniva modeato in fase di astrazione attraverso variabii egate in maniera indissoubie ad uno specifico e prefissato eemento de array. Pertanto i mio impegno è stato queo di ridefinire ed estendere i meccanismo di astrazione e raffinamento, per poter eseguire tai fasi su generici eementi di un array. La presente tesi è articoata nei seguenti capitoi: Ne primo capitoo verrà introdotto i probema dea verifica automatica, evidenziandone e probematiche e e strategie utiizzate per rendera 9

11 più efficiente e fattibie su un dominio sempre più esteso di programmi. Verrà dunque introdotto i paradigma CEGAR e verranno menzionati acuni too di verifica sviuppati secondo tae paradigma. Infine verrà introdotto e iustrato in maniera moto intuitiva i funzionamento di Eureka. I secondo capitoo iustra in maniera dattagiata a fase di astrazione. Dapprima verrà evidenziata a necessità di tae fase ne ambito dea verifica formae tramite tecniche di mode checking, successivamente verrà descritto i meccanismo di astrazione proposto ne presente avoro di tesi, mostrando i benefici che esso apporta a too. Infine verrà esibita una dimostrazione di correttezza dea strategia proposta. I terzo capitoo descrive i moduo di Mode Checking di Eureka, che si occupa di verificare a raggiungibiità di nodi rappresentanti stati di errore de programma, a interno de modeo astratto. Anche per i moduo di verifica verranno mostrate e modifiche apportate durante i presente avoro e presentata una dimostrazione di correttezza e competezza. Ne quarto capitoo vengono iustrati i modui di verifica e raffinamento utiizzati in Eureka. Infine, i quinto capitoo riguarda i dettagi impementativi de too. Verranno mostrati ed iustrati i principai agoritmi che impementano a fasi de processo di verifica, ponendo particoare attenzione ai modui esterni utiizzati a interno di Eureka. 10

12 Capitoo 1 Verifica di software Verificare a correttezza di un software risuta spesso fondamentae affinchè questo possa essere utiizzato con successo. Test e simuazione spesso non bastano a questo scopo. Per questo motivo c è bisogno di tecniche aternative, ad esempio i mode checking, che possano fornire informazioni certe circa acune caratteristiche de software in esame. In questo capitoo si introduce i tema dea verifica automatica e e sue probematiche. Si descrive a sua evouzione ne tempo e e souzioni che sono state trovate per rendera sempre più efficiente e per accrescere i numero di sistemi sui quai è possibie effettuare verifica formae. Si introduce quindi utiizzo di modei astratti per a verifica tramite tecniche di mode checking e come questi possano essere costruiti automaticamente attraverso utiizzo di strategie di verifica come i paradigma CEGAR. L attenzione verrà poi focaizzata su too Eureka, anaizzandone obiettivi appicativi, scete e strategie funzionai (mettendoe a confronto con e scete intraprese da atri too di verifica) e fornendone un esempio di esecuzione per iustrare intuizione de funzionamento dei vari modui che o compongono, a fine di preparare i ettore aa comprensione dee innovazioni apportate con i presente avoro di tesi. 1.1 Introduzione aa verifica formae Con i passare de tempo uomo è sempre più dipendente da sistemi compessi (ad esempio sistemi informatici, componenti eettronici e sistemi per e teecomunicazioni) e ciò rende sempre più importante che tai sistemi siano corretti. Sempicemente notando quai e quanti sistemi vengono utiizzati quotidianamente è possibie rendersi conto quanto a vita umana sia condizionata da eementi i cui corretto funzionamento è spesso considerato ovvio. Fra questi esistono sistemi a cui correttezza è un requisito fondamentae. 11

13 Tai sistemi vengono soitamente definiti safety critica, in quanto un oro errore potrebbe comportare non soo ingenti danni economici, ma anche seri rischi per a vita stessa. Nea maggior parte dei casi a verifica di correttezza, o megio de assenza di bugs, è affidata a varie fasi di test e simuazione. Tai tecniche si basano su utiizzo de sistema stesso (o di un suo modeo) ao scopo di verificare che, in funzione di un dato input, i comportamento de sistema sia queo desiderato. Purtroppo tae approccio è soggetto a impossibiità di verificare ogni input possibie de sistema in tempi accettabii. Tae imite comporta che se e fasi di test o simuazione permettono di verificare a presenza di un errore, esso è certo, ma se test e simuazione non trovano errori non è detto che non ce ne siano. La verifica formae supera tae imitazione perchè fornisce risposte esatte, a patto che sia stata utiizzata correttamente. Essa non opera su sistema concreto, bensì su un modeo a cui correttezza è fondamentae per a riuscita dea verifica. Un meccanismo di verifica formae controa che per tutti i possibii comportamenti de sistema vaga a proprietà che si desidera verificare. L anaisi è esaustiva su modeo formae, ed è possibie grazie a ragionamento simboico. In che modo i sistema e a proprietà devono essere espressi dipende da tipo di meccanismo che si usa per effettuare a verifica. Due meccanismi utiizzati per a verifica sono Theroem proving e Mode checking. I primo prevede che i sistema sia descritto attraverso un insieme Γ M di assiomi e regoe di inferenza, mentre a proprietà φ attraverso un teorema. I sistema di theroem proving cerca una dimostrazione per i teorema a partire dagi assiomi sfruttando e regoe di inferenza. I secondo prevede che i sistema sia descritto attraverso un sistema a transizioni etichettato (LTS) per indicare come i sistema evove ne tempo e che a proprietà da verificare sia espressa in un inguaggio accettato da mode checker. Un sistema a transizioni etichettato è una quadrupa (S, S 0, Act, R) dove: S è un insieme finito di stati; S 0 S è insieme degi stati iniziai; Act è un insieme di etichette; R S Act S è una reazione di transizione totae, ovvero per ogni s S esistono s S e a Act tai che (s, a, s ) R. Soitamente i inguaggio utiizzato per esprimere e proprietà è espresso in formue di ogiche temporai, che permettono di descrivere proprietà egate a tempo senza dovero rappresentare espicitamente [CGP99]. Una vota 12

14 costruito i modeo M e fornita a proprietà φ che si desidera verificare, i mode checker esegue una ricerca esaustiva suo spazio degi stati de modeo a fine di stabiire se a proprietà è soddisfatta in ogni suo stato. Questo equivae a dire che i comportamento de modeo è tae per cui, data una sua vautazione, a proprietà φ è sempre vaida, ovvero M = φ. Tae ricerca risuta particoarmene onerosa data a dimensione de modeo. Infatti i mode checker sono soggetti a probema de esposione degi stati [CGJ + 00b], ovvero aumentando i numero dee componenti de sistema cresce anche i numero degi stati de modeo. Tae crescita, in acuni casi, è esponenziae. Questo probema imita appicazione dee tecniche di mode checking a sistemi reativamente piccoi. 1.2 Mode checking simboico Per ridurre a quantità di memoria necessaria a immagazinare tutti gi stati presi in considerazione si è pensato di passare da una rappresentazione espicita degi stati ad una simboica. Grazie a McMian [BCM + 90] è stata sfruttata ne mode checking una nuova rappresentazione (simboica) definita da Bryant basata sui diagrammi binari di decisione (BDD) [Bry86]. In tae rappresentazione ogni stato è codificato mediante un assegnamento di vaori booeani a insieme di variabii di stato associate a sistema. Introducendo su queste strutture un ordinamento sue variabii ed appicando e regoe di riduzione si ottengono i Reduced Ordered Binary Decision Diagram ROBDD 1. E possibie, inotre, esprimere anche a reazione di transizione attraverso formue booeane in funzione di due insiemi di variabii, uno che codifica o stato di partenza dea transizione e uno che codifica o stato di arrivo dea transizione. Tae formua è poi rappresentata in un diagramma binario di decisione (ROBDD). Grazie a questo tipo di rappresentazione si è riusciti ad effettuare verifica su sistemi composti da più di stati [CGP99] e si sono ottenuti ottimi risutati nea verifica di circuiti eettronici isoati di medie dimensioni e sistemi i cui numero di stati non è eccessivamente ato. La rappresentazione degi stati tramite ROBDD non è unica possibie. Approcci differenti prevedono utiizzo di sistemi di vincoi sue variabii. Un sistema di vincoi ci permette di definire, per ogni variabie, uno o più sottoinsiemi de dominio entro i quae essa può assumere vaore. Tae approccio ci permette di esprimere in modo moto succinto anche insiemi infiniti 1 Gi ROBDD sono a tutti gi effetti una rappresentazione canonica di formue booeane, de tutto equivaente ad una tabea di verità o una formua proposizionae 13

15 e, per questo motivo, è particoarmente conveniente quando e variabii de modeo sono definite su un dominio numerico infinito. 1.3 Tecniche di astrazione per i software Un atro probema da affrontare quando si tenta di eseguire verifica automatica di software mediante mode checking deriva da impossibiità di eseguire tae tecnica su programmi con array. E necessario, quindi, mappare un programma da tae dominio ad un atro più sempice, per i quae sia possibie effettuare verifica tramite una procedura di mode checking. Tae mapping viene effettuato in fase di astrazione, durante a quae i programma concreto, definito a interno de dominio dei programmi ineari con array, viene trasformato in un programma astratto, appartenente, ne caso di Eureka, a dominio dei programmi ineari. Tae corrispondenza deve, però, garantire una certa reazione tra programma astratto e concreto in merito ae proprietà da verificare, in particoare sarebbe auspicabie che una proprietà fosse vaida ne programma astratto se e soo se o è ne programma concreto, in modo da poter estendere anche a programma concreto esito dea verifica di una determinata proprietà su programma astratto. Nei programmi ineari con array, ed in particoare in Eureka, astrazione utiizzata è conservativa ed in quanto tae permette di affermare soo un verso de impicazione e cioè che, se una proprietà risuta vaida ne programma astratto, aora o è anche in queo concreto; non vae però i contrario, infatti una proprietà che risuta vioata da una traccia di esecuzione de programma astratto, potrebbe comunque essere vaida ne programma concreto, dove tae traccia di esecuzione non è fattibie. Tai tracce di esecuzione, ammissibii ne modeo astratto ma non ne programma concreto, sono definite spurie 2. Trovare i giusto iveo di dettagio per a costruzione de modeo astratto è aa base dea riuscita dea verifica. Sono stati introdotti vari meccanismi per a costruzione automatica de modeo che cercano di trovare a giusta astrazione attraverso raffinamenti sempre più dettagiati di un modeo di partenza. Carke descrive una procedura di Astrazione-Raffinamento guidato da controesempi (CEGAR, Counter Exampe Guided Abstraction Refinement) grazie a quae è possibie giungere a giusto iveo di astrazione [CGJ + 00a]. Considerato un modeo K e una proprietà p da verificare, tae procedura prevede un cico di astrazione-verifica-raffinamento, iustrato in figura 1.1, che può essere schematizzato nee seguenti fasi: 2 Per maggiori chiarimenti si rimanda a capitoo 2 14

16 Figura 1.1: Cico CEGAR 1. Astrazione: i modeo concreto K viene mappato ne suo modeo astratto K 2. Verifica: viene effettuata a verifica, tramite mode checking, dea proprietà p su modeo astratto K. Se a proprietà risuta vaida ne modeo astratto (K = p), aora o è anche ne modeo concreto K, essendo astrazione conservativa, pertanto i cico termina affermando che a proprietà è verificata da modeo concreto (K = p). Se, invece, daa verifica risuta che K = p, aora i mode checker fornisce un controesempio T (traccia de modeo astratto) che fasifica a proprietà 3. Simuazione: a traccia T viene anaizzata, per verificarne a fattibiità in K, tramite un theorem proving. In atre paroe si verifica che T appartenga anche a insieme di tracce ammissibii de programma concreto. Se T è una traccia fattibie de programma concreto, aora i cico termina fornendo a traccia di esecuzione T che fasifica p; se invece T è una traccia spuria, aora va eiminata da modeo astratto 4. Raffinamento: si occupa proprio di individuare gi eementi che erano stati ignorati nea precedente astrazione e che, introdotti ne nuovo modeo astratto, garantiscono che a traccia spuria T non faccia più parte di esso 15

17 5. Ritorna a passo 1 I cico descritto da Carke è approccio sceto per a reaizzazione di moti too di verifica basati su mode checking, fra i quai si cita i progetto SLAM di Microsoft utiizzato per reaizzare SDV (Static Driver Verifier), too per a verifica dei driver per Windows. Tuttavia, i paradigma CEGAR non è unico approccio possibie. Henzinger, Jhaa, Majumdar e Sutre suggeriscono una variante a tae cico. L idea introdotta prevede i raffinamento a richiesta, ovvero si raffinano soo quee regioni di codice in cui è necessaria un astrazione più vicina a modeo concreto. Grazie a controesempio si determina quae regione di codice deve essere raffinata e, a partire da questa, si crea un nuovo iveo di astrazione, reativo aa regione in questione, tae da rendere i controesempio non più fattibie. A questo punto a verifica può ripartire proprio daa regione di codice appena raffinata [HJMS02]. Tae approccio prende i nome di Lazy Abstraction e ha i vantaggio di avere regioni di codice astratte con granuarità differenti e di evitare di eseguire più vote a verifica su regioni di codice i cui iveo di astrazione non cambia. Tae tecnica però risuta particoarmente onerosa per a verifica di sistemi di grandi dimensione. I too di verifica reaizzato a Berkeey che sfrutta tae tecnica prende i nome di BLAST (Berkeey Lazy Abstraction Software verification Too) [HJMS03]. I modui di mode checking di SLAM e BLAST cacoano a raggiungibiità di acuni stati adeguatamente etichettati. Infatti, i probema di stabiire se un programma sequenziae P gode di una quache proprietà φ può essere ridotto ad un probema di vioazione di un affermazione (assertion faiure) in una versione propriamente modificata de programma di partenza. Poichè ci si aspetta che ogni proprietà φ vaga in ogni stato de modeo, ovvero che φ sia un invariante de programma, a sua negata non deve essere mai possibie. Aggiungendo quindi in P, per ogni proprietà φ, de codice extra che può essere raggiunto soo se φ è verificata, si riduce i probema dea verifica di φ a cacoo dea raggiungibiità de codice che esprime φ [BR00a]. 1.4 Domini di astrazione La fase di astrazione consiste dunque nea traduzione di un programma da un dominio concreto ad un dominio astratto più sempice e su cui è possibie eseguire a procedura di verifica. Ne ambito de software mode checking sceta moto diffusa è utiizzare i dominio dei programmi booeani come dominio di astrazione, infatti questo dominio si presta particoarmente aa verifica formae di software per due 16

18 motivi: primo, i numero di stati di un programma booeano è finito, quindi i probema dea raggiungibiità è decidibie; secondo, i programmi booeani hanno gi stessi costrutti di controo di un inguaggio di programmazione procedurae. Un esempio di appicazione de paradigma CEGAR per a verifica di software su un dominio astratto costituito dai programmi booeani è i progetto SLAM di Microsoft [BMMR01]. Infatti esso prevede che i modei astratti siano rappresentati con programmi booeani e a rappresentazione simboica di stati e transizioni avviene tramite ROBDD. E evidente, comunque, che i costo dea verifica è direttamente proporzionae a numero di iterazioni de cico e, proprio per ridurre tae numero, si è deciso di utiizzare a interno di Eureka un dominio astratto, queo dei programmi ineari, i più vicino possibie a queo concreto dei programmi ineari con array, differentemente da quanto fatto da SLAM dea Microsoft, in modo da avere astrazioni con un minor numero di tracce spurie e conseguentemente un minor numero di iterazioni Astrazione-Raffinamento. 1.5 Un esempio di esecuzione di Eureka I progetto Eureka [ABM06] nasce con obiettivo di reaizzare un too per a verifica formae di software. Specificatamente, i too è in grado di verificare i frammento di inguaggio C corrispondente a dominio dei programmi ineari con array (in reatà a casse di programmi verificati da Eureka è rappresentata da un estensione di tae dominio, i dominio dei programmi ineari con array generaizzati, introdotto in sezione 2.1). Per descrivere in maniera un po più dettagiata i comportamento dee varie fasi de cico, viene presentato di seguito un esempio di esecuzione di Eureka su programma di tabea 1.1 La prima iterazione comincia con a costruzione de modeo P 0, mostrato in tabea 1.2, i cui iveo di astrazione è massimo. Costruire un modeo astratto a partire da uno concreto significa, in pratica, sempificare i modeo concreto ignorando parte de informazione in esso contenuta. In Eureka informazione che viene astratta è quea riguardante i vaore di acune variabii ed array de programma. Infatti, acune variabii vengono eiminate da modeo astratto e sostituite da simboo u (indefinito) in tutte e espressioni in cui compaiono e gi assegnamenti ad esse vengono sostituiti da istruzione vuota (skip). Ma più interessante è vedere cosa accade con gi array de programma, visto che scopo primario de astrazione è costruire un modeo che non preveda a oro presenza, probematica per i mode checker. 17

19 P void main() { int i, a[3]; [1] a[1] = 1; [2] i = 0; [3] whie ( (a[i]!= 1) && (i < 3) ) { [4] a[i] = 2*i; [5] i = i+1; } [6] assert (i <= 1); } Tabea 1.1: Un sempice programma P su cui viene mostrato un esempio di esecuzione di Eureka In fase di astrazione, gi array non vengono più considerati nea oro interezza, ma vengono tradotti ne modeo astratto con una variabie scaare per ogni eemento. Così, un generico array a di dimensione 5, verrà tradotto, ne modeo astratto, da insieme di variabii scaari {a 0, a 1, a 2, a 3, a 4 }. Ancora una vota, non tutte e variabii corrispondenti ad eementi de array faranno parte de modeo astratto, ma soo un oro sottoinsieme, individuato da insieme R(a) {0, 1,..., dim(a) 1} di indici de array a tae che se i R(a) aora a i sarà una variabie de modeo astratto per ogni i {0, 1,..., dim(a) 1}. Quindi, ogni accesso a[i] ad array presente in un espressione de programma concreto, viene sostituito, in queo astratto, da istruzione condizionae (i==k 1 )?a k1 :(i==k 2 )?a k2 :...:(i==k n )?a kn :u con R(a) = {k 1,...,k n }. Intuitivamente, se i vaore de espressione i che indicizza accesso ad array è uguae ad uno degi indici numerai presenti in R(a), e cioè se vae i = k j per quache k j R(a), aora espressione a[i] viene sostituita daa variabie astratta a kj, corrispondente proprio a eemento k j -esimo de array a; se invece espressione i non è uguae a nessuno dei numerai in R(a) (i k j per ogni k j R(a)), espressione a[i] è sostituita da simboo u. Invece, ogni assegnamento ad array a[i]=e; viene sostituito da assegnamento paraeo a k1 =(i==k 1?e:a k1 ), a k2 =(i==k 2?e:a k2 ),...,a kn = (i==k n?e:a kn ); con R(a) = {k 1,...,k n }. Intuitivamente, viene modificata soo a variabie 18

20 che cattura i comportamento dea ocazione de array identificata da espressione i. I vaore dee variabii astratte che modeano atre ocazioni de array non viene modificato. Quindi, un modeo astratto viene generato a partire da un sottoinsieme V de insieme V di variabii scaari de programma e da una casse di insiemi di indici I = {R(a) a A}, dove A rappresenta insieme degi array de programma. Tuttavia, per sempicità di trattazione, ne corso de presente eaborato, i modei astratti saranno generati sempre rispetto a intero insieme di variabii scaari; unica informazione astratta da modeo astratto è quea riguardante gi array de programma, si dirà quindi che un modeo è stato generato rispetto ad una casse di insiemi di indici I, sottointendendo che astrazione avviene anche rispetto a intero insieme V di variabii di programma. Ritornando a esempio di esecuzione, astrazione dea prima iterazione avviene, come già detto, con i massimo iveo di astrazione, cioè tutta informazione de programma astratto (si ricorda che ci si riferisce sempre a informazione reativa a variabii array) è ignorata. I programma astratto viene costruito rispetto aa casse di insiemi vuoti di indici I = {R(a) a A P }, dove R(a) = per ogni a A P P 0 void main() { int i; [1] ; [2] i = 0; [3] whie ( (u!= 1) && (i < 3) ) { [4] ; [5] i = i+1; } [6] assert (i <= 1); } Tabea 1.2: Astrazione iniziae P 0 di P Su tae modeo viene eseguita a procedura di mode checking, iustrata ne capitoo 3, che rivea a presenza di una traccia τ che porta a faimento de istruzione assert (assert faiure). La traccia in questione viene sottoposta a test di fattibiità ne programma concreto P, attraverso a fase di simuazione, che consiste nea gene- 19