Bounded Model Checking Using Java PathFinder

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

BOUNDED MODEL CHECKING

V N ´

ASTROJI JAVA PATHFINDER

DIPLOMOV ´

A PR ´

ACE

MASTER’S THESIS

AUTOR PR ´

ACE

Bc. VENDULA HRUB ´

A

AUTHOR

(2)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

BOUNDED MODEL CHECKING

V N ´

ASTROJI JAVA PATHFINDER

BOUNDED MODEL CHECKING USING JAVA PATHFINDER

DIPLOMOV ´

A PR ´

ACE

MASTER’S THESIS

AUTOR PR ´

ACE

Bc. VENDULA HRUB ´

A

AUTHOR

VEDOUC´I PR ´

ACE

Ing. BOHUSLAV K ˇ

RENA, Ph.D.

SUPERVISOR

(3)

Abstrakt

Diplomová práce je vˇenovaná aplikaci formáln´ı metody bounded model checking pro au-tomatickou opravu chyb. Oprava se specializuje na chyby spojené se soubˇeˇznost´ı. Práce je zamˇeˇrena na programy napsané v jazyce Java, a proto pro verifikaˇcn´ı metodu byl zvolen mo-del checker Java Pathfinder, který je urˇcen pro Java programy. Vlastn´ı verifikaˇcn´ı metoda spoˇc´ıvá v aplikaci strategie pro navigaci stavovým prostorem do m´ısta verifikace. Z daného m´ısta je spuˇstˇen bounded model checking pro ovˇeˇren´ı opravy. Navigace stavovým prosto-rem je implementována pomoc´ı strategie record&replay trace. Pro aplikaci bounded model checkingu jsou implementovány dalˇs´ı parametry a moduly pro verifikaci speciáln´ıch vlast-nost´ı systému, které ovˇeˇruj´ı koreknost opravy chyby. Bounded model checking se provád´ı v okol´ı opravy.

Kl´ıˇ

cov´

a slova

Model Checking, Java PathFinder, Bounded model checking, verifikace, Record&Replay trace, automatick´a oprava, soubˇeˇznost, ovˇeˇrov´an´ı opravy

Abstract

This thesis deals with the application of bounded model checking method for self-healing as-surance of concurrency related problems. The self-healing is currently interested in the Java programming language. Therefore, it concetrate mainly on the model checker Java PathFin-der which is built for handling Java programs. The verification method is implemented like the Record&Replay trace strategy for navigation through a state space and performance bounded model checking from reached state through the use of Record&Replay trace stra-tegy. Java PathFinder was extended by new moduls and interfaces in order to perform the bounded model checking for self-healing assurance. Bounded model checking is applied at the neighbourhood of self-healing.

Keywords

Model Checking, Java PathFinder, Bounded model checking, verification, Record&Replay trace, self-healing, concurrency, healing assurance

Citace

Vendula Hrubá: Bounded model checking v nástroji Java PathFinder, diplomová práce, Brno, FIT VUT v Brnˇe, 2008

(4)

Bounded model checking

v n´

astroji Java PathFinder

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto diplovomou pr´aci vypracovala samostatnˇe pod veden´ım pana Ing. Bohuslava Kˇreny, Ph.D.

. . . . Vendula Hrub´a 19. kvˇetna 2008

Podˇ

ekov´

an´ı

Chtˇela bych podˇekovat celé své rodinˇe, prátel˚um a spoluˇzák˚um za jejich podporu a pomoc pˇri studiu.

Tato práce byla podpoˇrena Evropskou uni´ı v rámci FP6-IST projektu SHADOWS (ˇc. smlou-vy IST-035157). Za obsah práce odpov´ıdá pouze jej´ı autor. Tato práce nevyjadˇruje názor Evropské unie a Evropská unie nen´ı odpovˇedná za uˇzit´ı jakékoliv informace v práci uvedené.

Acknowledgment

This work is supported by the European Community under the Information Society Techno-logies (IST) programme of the 6th FP for RTD – project SHADOWS contract IST-035157. The authors are solely responsible for the content of this thesis. It does not represent the opi-nion of the European Community, and the European Community is not responsible for any use that might be made of data appearing therein.

c

Vendula Hrub´a, 2008.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ av-nˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(5)

Obsah

1 Uvod´ 3

2 Rozbor problematiky 5

2.1 Proces automatick´e opravy . . . 5

2.1.1 Princip opravy probl´emu . . . 6

2.1.2 Princip ovˇeˇren´ı opravy . . . 7

2.2 Form´aln´ı metody . . . 7

3 Model Checking 10 3.1 Model syst´emu . . . 11

3.2 Specifikace syst´emu. . . 12

3.3 V´ystup verifikace . . . 14

3.4 Probl´em stavov´e exploze . . . 14

3.5 Bounded Model Checking . . . 16

3.6 Navigace stavov´ym prostorem . . . 17

4 Java PathFinder 19 4.1 Z´akladn´ı charakterisitika . . . 20

4.2 Specifikace. . . 21

4.3 Prohledáván´ı stavového prostoru . . . 22

4.4 Rozˇsiˇritelnost . . . 24

5 Implementace 25 5.1 Record&Replay trace v JPF . . . 26

5.1.1 Record&Replay pomoc´ı ChoiceGener´ator˚u. . . 27

5.1.2 Record&Replay pomoc´ı byte-code instrukc´ı . . . 28

5.1.3 Pˇr´ıklad na Record&Replay trace . . . 31

5.2 Bounded model checking v JPF . . . 33

5.2.1 Pˇr´ıklad na Bounded Model Checking . . . 35

5.3 Modifikace Replay trace pro projekt SHADOWS . . . 37

5.3.1 Replay trace pomoc´ı p˚uvodn´ım k´odu . . . 39

5.3.2 Replay trace pomoc´ı instrumentovan´eho k´odu . . . 39

5.4 V´ysledky a Testy . . . 41

5.4.1 Rychlost bˇehu programu ve pouˇzit´ych n´astroj´ıch . . . 42

5.4.2 Rychlost metody Record&Replay trace. . . 43

(6)

(7)

Kapitola 1

´

Uvod

V dneˇsn´ı dobˇe se setkáváme s poˇc´ıtaˇci nebo poˇc´ıtaˇcovými programy témˇeˇr na kaˇzdém kroku. At’ uˇz se jedná o mobiln´ı telefony, bankovn´ı úˇcty, pr˚umyslové stroje nebo ˇr´ıd´ıc´ı stˇrediska. Vˇzdy chceme, aby nám naˇse pˇr´ıstroje pracovaly správnˇe, coˇz ale jiˇz z principu nelze. O ˇzádném rozsáhlejˇs´ım programu nem˚uˇzeme prohlásit, ˇze neobsahuje chyby, lze pouze ˇr´ıci, jaké chyby neobsahuje. Jsou pˇr´ıpady, kdy nám nevad´ı, ˇze program

”zatuhne“ nebo provede neplatnou akci, napˇr. pˇri pos´ılán´ı emailu se nepodaˇr´ı komunikace se serverem, email se neodeˇsle a jeho obsah je ztracen. V takovém pˇr´ıpadˇe nás chyba zamrz´ı, mus´ıme email napsat znova. M˚uˇze ovˇsem nastat situace, kdy se jedná o d˚uleˇzité události, které mohou zp˚usobit závaˇznˇejˇs´ı problémy – nepˇriˇcten´ı správné ˇcástky na bankovn´ı úˇcet, porucha na lékaˇrských pˇr´ıstroj´ıch, atd. V takovém pˇr´ıpadˇe rozhodnˇe nechceme, aby program zatuhl nebo vykonal neoˇcekávanou akci. Z toho d˚uvodu se vynakládá spousta penˇez na testován´ı a ovˇeˇrován´ı korektnosti program˚u, aby programy vykonávaly pouze poˇzadované události.

I pˇres veˇskeré snahy v programech z˚ustávaj´ı chyby, které se dostanou aˇz k uˇzivateli. Dává tedy smysl se zabývat opravou tˇechto chyb, které se neodhal´ı pˇri testován´ı a snaˇzit se je opravit za bˇehu aplikace. Právˇe o to se snaˇz´ı projekt SHADOWS, jehoˇz souˇcást´ı je i tato diplomová práce. SHADOWS – A Self-healing Approach to Designing Complex Software Systems je evropský projekt, který se zabývá procesem automatické opravy (self-healing approach). Princip procesu a jeho c´ıl se daj´ı specifikovat pomoc´ı následuj´ıc´ıch ˇctyˇr základn´ıch krok˚u:

1. zjiˇstˇen´ı problému (problem detection) – pˇredt´ım neˇz se zaˇcne s opravou (léˇcen´ım) je potˇreba urˇcit, zda je v systému nˇejaký problém a ˇceho se týká,

2. nalezen´ı pˇr´ıˇciny problému (problem localization) – druhým krokem po urˇcen´ı moˇzného problému v systému je tˇreba tento problém lokalizovat resp. urˇcit m´ısto v programu (sledovaném systému), kde se problém vyskytuje,

3. oprava problému (problem healing) – dalˇs´ım krokem je výbˇer akce, ze seznamu nab´ızených léˇc´ıc´ıch akc´ı, které je moˇzné pro opravu detekovaného problému pouˇz´ıt, 4. ovˇeˇren´ı opravy (problem assurance) – posledn´ım krokem je ovˇeˇren´ı, zda

pro-vedn´ı opravné akce nezp˚usobilo v systému jiný problém. Léˇc´ıc´ı akce zmˇen´ı chován´ı systému, pˇredpokládáme, ˇze se nyn´ı systém bude chovat korektnˇe vzhledem k urˇceným poˇzadavk˚um. Nicménˇe opravná akce m˚uˇze zmˇenit chován´ı systému takovým zp˚usobem, ˇze se objev´ı jiný problém. Z toho d˚uvodu je potˇreba provést ovˇeˇren´ı opravy.

(8)

Projekt SHADOWS se zabývá splnˇen´ım funkˇcn´ıch poˇzadavk˚u, výkonem a v neposledn´ı ˇradˇe správným pouˇzit´ım soubˇeˇzného provádˇen´ı v programu. Fakulta informaˇcn´ıch techno-logi´ı se v projektu vˇenuje ˇcásti zamˇeˇrené na soubˇeˇzné provádˇen´ı (concurrency). Pˇresnˇeji se vˇenuje léˇcen´ı chyb, které vznikaj´ı pomoc´ı paralelismu resp. soubˇeˇznosti v systému. Jedná se o chyby typu deadlocks, data races, lost notification, atd. Léˇcen´ı se zamˇeˇruje na opravy chyb v Java programech, ve kterých se soubˇeˇznost implementuje velice snadno pomoc´ı vláken.

Tato diplomová práce je vˇenovaná posledn´ımu z uvedených krok˚u opravného procesu – ovˇeˇren´ı léˇc´ıc´ı akce. K tomu, aby bylo moˇzné navrhnout vhodnou metodu pro ovˇeˇren´ı léˇc´ıc´ı akce, je zapotˇreb´ı znát, co léˇc´ıc´ı akce provád´ı a jakým zp˚usobem funguje. Pokud známe princip opravné akce, je moˇzné navrhnout a posléze implementovat metody pro ovˇeˇren´ı korektnosti opravy.

Dalˇs´ı text je dˇelen do následuj´ıc´ıch kapitol. V druhé kapitole jsou podrobnˇeji rozepsány jednotlivé kroky opravného procesu pro lepˇs´ı porozumˇen´ı celého procesu opravy. Dále jsou zde struˇcnˇe popsány formáln´ı metody, ze kterých byla pro ovˇeˇren´ı opravy zvolena metoda model checking. O model checkingu, jeho základech a principu pojednává tˇret´ı kapitola. Zde jsou také popsány jeho modifikace, problém stavové exploze a jeho moˇzná ˇreˇsen´ı. Ve ˇctvrté kapitole jsou nejprve uvedeny r˚uzné model checkery, ze kterých byl pro verifikaci zvolen mo-del checker – Java PathFinder. Jeho popis a nastaven´ı jeho vlastnost´ı jsou v této kapitole také uvedeny. Dalˇs´ı kapitola popisuje hloubˇeji zvolenou metodu pro verifikaci systému z hle-diska implementace v Java PathFinderu. Jsou zde uvedeny pˇr´ıklady a dosaˇzené výsledky. Posledn´ı kapitolou je závˇer, který obsahuje shrnut´ı výsledk˚u a nástin dalˇs´ı práce na pro-jektu.

(9)

Kapitola 2

Rozbor problematiky

2.1 Proces automatick´

e opravy

V následuj´ıc´ıch odstavc´ıch budou podrobnˇeji rozepsány jednotlivé kroky procesu automa-tické opravy. Kroky procesu popisuj´ı princip léˇcen´ı chyb, které vznikaj´ı soubˇeˇznost´ı v Java programech [12].

Zjiˇstˇen´ı problému. V prvn´ım kroku se monitoruje vykonáván´ı programu. Monito-rován´ı prob´ıhá pomoc´ı instrumentace programu nad byte-codem. Pokud by se chyba hledala na úrovni byte-codu pomoc´ı ladˇen´ı (debugging), je velká pravdˇepodobnost, ˇze chyba ne-bude nalezena. Program na úrovni byte-codu umoˇzˇnuje velké mnoˇzstv´ı moˇznost´ı prokládán´ı instrukc´ı a t´ım se sniˇzuje pravdˇepodobnost nalezen´ı chyby bˇehem testován´ı. Pomoc´ı instru-mentace se do programu zavád´ı také ˇsum (dalˇs´ı instrukce), pomoc´ı kterých se zvyˇsuje pravdˇepodobnost odhalen´ı chyb vzniklých nesprávným prokládán´ım instrukc´ı (data race). Instrumentace kódu se provád´ı pomoc´ı nástroje ConTest, který pracuje nad Java byte-codem a jehoˇz bliˇzˇs´ı popis a specifikace jsou uvedeny v [5]. ConTest je nástroj vyv´ıjený výzkumnou laboratoˇr´ı IBM pro testován´ı Java program˚u, které obsahuj´ı v´ıce vláken [6].

Nalezen´ı pˇr´ıˇciny problému. Nalezen´ı pˇr´ıˇciny problému je obt´ıˇzný úkol i pro ˇclovˇeka, t´ım tˇeˇzˇs´ım úkolem se stává navrˇzen´ı mechanizmu pro automatickou detekci pˇr´ıˇciny chyby. V projektu SHADOWS byly navrˇzeny metody pro automatickou detekci. Prvn´ı meto-dou je správný odhad a výbˇer opravné akce ze speciáln´ıho seznamu, který byl navrˇzen pro výbˇer správné opravy chyb vzniklých soubˇeˇznost´ı. Jedná se o následuj´ıc´ı detektory: da-taRace detektor, atomRace detektor nebo deadlock detektor. Jinou moˇznost´ı je provádˇen´ı velkého mnoˇzstv´ı test˚u s r˚uznými body instrumentace a následné statistické vyhodno-cen´ı dosaˇzených výsledk˚u. Pomoc´ı z´ıskaných statistických dat a korektnosti chován´ı pro-gramu v daném testu se dá urˇcit problém. Oba výˇse popsané pˇr´ıstupy lze kombinovat s formáln´ımi metodami (napˇr. model checkingem, statickou analýzou) a pomoc´ı nich sn´ıˇzit poˇcet false alarm˚u. False alarmy vznikaj´ı v pˇr´ıpadˇe, pokud je nadetekován problém, který ve skuteˇcnosti v programu nen´ı. Z principu funkce formáln´ıch metod, by se tyto metody daly aplikovat na samotnou lokalizaci problému v systému. Nicménˇe jejich aplikace na reálný systém je problematická z d˚uvodu stavové exploze. Ta je kritickým problémem formáln´ıch metod, který brán´ı jejich nasazen´ı na reálné systémy a proveden´ı jejich celkové verifikaci.

Oprava problému. Nástroj (tool) pro opravu problému m˚uˇze být zaloˇzen na výbˇeru opravné akce, které jsou vyjmenovány ve speciáln´ım seznamu. Zvolená oprava detekovaného problému m˚uˇze být nab´ıdnuta vývojáˇri jako moˇzné ˇreˇsen´ı bˇehem vývoje systému. Vývojáˇr se pak sám rozhodne, zda nab´ızenou akci provede ˇci nikoliv. C´ılem projektu je ovˇsem

(10)

léˇcit chyby, které se projev´ı u uˇzivatele. Zámˇerem je tedy léˇcit chyby, které se jiˇz jednou v systému vyskytly a na nˇe aplikovat opravu, a t´ım zamezit jejich opˇetovnému výskytu v aplikaci u uˇzivatele. Prozat´ım se léˇc´ıc´ı akce zamˇeˇruj´ı na problémy typu data races. Data races vznikaj´ı v d˚usledku paraleln´ıho pˇr´ıstupu ke sd´ılené promˇenné ve stejný ˇcasový okamˇzik z v´ıce m´ıst, jehoˇz d˚usledkem je konfliktn´ı zápis do sd´ılené promˇenné. Moˇzným ˇreˇsen´ım odstranˇen´ı problému data race je pˇridán´ı zámk˚u (locks). Pˇresnˇejˇs´ı popis jednotlivých oprav i samotného problému data race je bl´ıˇze uveden v [1,12].

Ovˇeˇren´ı opravy. Posledn´ım krokem procesu je ovˇeˇren´ı opravné akce. Bylo by chybné pˇredpokládat, ˇze lze navrhnout univerzáln´ı opravu urˇcitého problému, která by fungovala za vˇsech okolnost´ı. Z toho d˚uvodu jsou navrˇzeny speciáln´ı léˇc´ıc´ı akce pro konkrétn´ı pˇr´ıpady výskytu urˇcitého problému. Proto je také potˇreba ovˇeˇrit, zda zvolená oprava chyby byla ´

uspˇeˇsná a bezpeˇcná (napˇr. ovˇeˇren´ı zda pˇridán´ı zámk˚u pro odstranˇen´ı problému data race, nezp˚usobilo jiný problém – deadlock, apod.). Ke kontrole opravy je vhodné pouˇz´ıt formáln´ı verifikaci, jedná se efektivn´ı metody pro ovˇeˇrován´ı správnosti systému. Mezi formáln´ı me-tody patˇr´ı model checking, statická analýza nebo theorem proving. V pˇr´ıpadˇe jejich omezen´ı resp. modifikace je lze aplikovat na reálný systém a zverifikovat ho.

Jak jiˇz bylo uvedeno v úvodu, k tomu aby bylo moˇzné navrhnout správnou metodu pro ovˇeˇren´ı opravy, je potˇreba znát jej´ı podstatu a zp˚usob aplikace na problém resp. chybu.

2.1.1 Princip opravy probl´emu

Pˇredpokládejme, ˇze v monitorovaném systému byl lokalizován problém. Ten se nacház´ı ve speciáln´ım seznamu problém˚u, pro které jsou navrˇzeny léˇc´ıc´ı akce. Posléze se zvolená léˇc´ıc´ı akce aplikuje na detekovaný problém, a ta problém v programu oprav´ı [1]. Existuj´ı dvˇe moˇznosti jak opravu na problém aplikovat. Prvn´ı moˇznost´ı je pouze navrˇzen´ı opravy vývojáˇri, který se sám rozhodne, zda ji na opravu pouˇzije ˇci nikoliv. Druhou vhodnˇejˇs´ı metodou je pouˇzit´ı arichitektury listener˚u. Listenery umoˇznuj´ı modifikovat chován´ı systému za jeho bˇehu bez nutnosti explicitn´ıho zásahu do zdrojového kódu. Architektura listener˚u je souˇcást´ı jiˇz zmiˇnovaného nástroje ConTest [5,16].

Oprava pomoc´ı plánován´ı. D´ıky monitorován´ı (sledován´ı) systému za jeho bˇehu vzniká v bˇehu programu ˇsum, resp. v programu se vykonává v´ıce instrukc´ı neˇz v bˇeˇzném bˇehu programu bez monitorován´ı. Pomoc´ı tohoto mechanizmu je snadnˇejˇs´ı odhalit chyby vzniklé soubˇeˇznost´ı, které se projevuj´ı pouze pˇri urˇcitém prokládán´ı instrukc´ı. K nesprávn´ e-mu prokládán´ı instrukc´ı vedouc´ı k chybˇe docház´ı napˇr´ıklad pˇri vyt´ıˇzen´ı procesoru jinými programy, které nejsou bˇeˇznˇe pˇri testován´ı programu spuˇstˇeny. Proto monitorován´ı, které také potˇrebuje porvádˇet vlastn´ı instrukce umoˇznuje odhalen´ı tˇechto chyb. Pro opravu po-dobných chyb v Java programech je nˇekdy postaˇcuj´ıc´ı zavolán´ı metody yield(). Metoda se zavolá pˇred kritickou seck´ı, kde docház´ı k chybˇe. Princip metody yield() spoˇc´ıvá v pˇrepnut´ı kontextu na jiné vlákno (aktuáln´ı vlákno se vzdává procesoru), pˇri dalˇs´ım pˇridˇelen´ı proce-soru je jiˇz dostatek ˇcasu na vykonán´ı kritické sekce vcelku (bez pˇrepnut´ı kontextu). Uvede-nou techniku lze kombinovat s pˇridˇelován´ım r˚uzných priorit vlákn˚um. V takovém pˇr´ıpadˇe do kritické sekce m˚uˇze vstoupit nebo ji pˇreruˇsit pouze vlákno se stejnou nebo vyˇsˇs´ı prioritou. Oprava pomoc´ı synchronizace. Zmiˇnovaná ˇcást projektu SHADOWS je zamˇeˇrena na chyby, které jsou zp˚usobeny nevhodným pouˇzit´ım synchronizace, nebo kdyˇz synchroni-zace zcela chyb´ı. V pˇr´ıpadˇe chybného pouˇzit´ı synchronizace obsahuje oprava vhodnou zmˇenu v synchronizaci. Pokud se jedná o problém chybˇej´ıc´ı synchronizaci nad sd´ılenou promˇennou, je tˇreba vˇenovat dostateˇcnou pozornost pˇridán´ı zámku. Zámek je potˇreba vloˇzit takovým

(11)

zp˚usobem, aby jeho pˇridán´ı nezp˚usobilo jiný problém v systému, typickým problémem je vznik deadlocku. Je tedy nutno ovˇeˇrit, zda pˇridán´ı zámk˚u skuteˇcnˇe vyˇreˇsilo problém (data race) a dále zverifikovat, ˇze zm´ınˇená oprava nezp˚usobila v systému jiný problém.

2.1.2 Princip ovˇeˇren´ı opravy

Pro ovˇeˇren´ı opravy je moˇzné pouˇz´ıt techniky formáln´ı verifikace jako model checking, sta-tickou analýzu atd. K tomu, aby bylo moˇzné formáln´ı metody aplikovat na reálný systém, je tˇreba udˇelat jejich omezen´ı nebo urˇcitou modifikaci. V tomto pˇr´ıpadˇe – ovˇeˇrován´ı opravy, nen´ı c´ılem zverifikovat celý systém, ale pouze okol´ı léˇcené chyby. Jde tedy o aplikaci formáln´ı metody na konkrétn´ı ˇcást programu a na kompletn´ı reálný systém. Aplikace formáln´ı me-tody m˚uˇze vypadat následovnˇe.

Pouˇzit´ı statické analýzy nad byte-codem: v pˇr´ıpadˇe pouˇzit´ı opravné akce – pˇridán´ı zámk˚u (lock/unlock) je tˇreba ovˇeˇrit, zda nové zámky nejsou v kolizi s jiˇz naimplementovanou synchronizac´ı. Pˇr´ıpadná kolize synchronizace by mohla zp˚usobit deadlock. Problém data races se ˇcasto vyskytuje nad jednoduchými pˇr´ıkazy (malá ˇcást kódu). Provést statickou analýzu nad malou ˇcást´ı kódu nen´ı problém a tud´ıˇz odhalen´ı daného problému je moˇzné.

Pro pouˇzit´ı model checkingu se je nejprve potˇreba dostat do poˇzadovaného stavu resp. do jeho okol´ı a zde posléze provést bounded model checking. Bounded model checking se provede do pˇredem urˇcené hloubky stavového prostoru. K prohledáván´ı stavového prostoru existuj´ı r˚uzné heurisitiky, dále je potˇreba pro prohledáván´ı stavového prostoru zadat r˚uzné specifikace, které maj´ı být v systému splnˇeny (verifikovány).

Pokud opravná akce zp˚usob´ı jiný problém a pomoc´ı ovˇeˇrován´ı opravy se daný problém zjist´ı, je potˇreba upravit léˇc´ıc´ı akci tak, aby k nové chybˇe nedocházelo nebo zvolit jinou léˇc´ıc´ı akci. Po zmˇenˇe opravy je tˇreba provést nové ovˇeˇren´ı bˇehu programu, zda se jiˇz systém chová korektnˇe. Stále zde ale pˇretrvává problém moˇzného výskytu chyb. Verifikace systému nebo ˇ

cásti systému se provád´ı vˇzdy vzhledem k nˇejakým konkrétn´ım vlastnostem a specifikac´ım. Stále tedy neˇreˇs´ı problém, kdy o ˇzádném systému nelze ˇr´ıci, ˇze je bezchybný. O programu lze pouze ˇr´ıci, které chyby neobsahuje. Pokud je znám princip opravy, je moˇzné navrhnout a posléze implementovat takovou metodu pro ovˇeˇren´ı korektnosti opravy, která ovˇeˇr´ı ty specifikace, u kterých bˇehem léˇcen´ı doˇslo ke zmˇenˇe.

2.2 Form´

aln´ı metody

Formáln´ı metody jsou zaloˇzeny na matematických metodách, um´ı dokázat/vyvrátit urˇcité specifikace systému. Formáln´ımi metodami rozum´ıme verifikaˇcn´ı nebo analytické metody.

Verifikace ovˇeˇruje zadané vlastnosti v systému. Napˇr´ıklad v paraleln´ıch programech m˚uˇze verifikace odpovˇedˇet na otázku, zda se v programu vyskytuje deadlock. Verifikace tedy vrac´ı odpovˇed’ ano/ne podle toho, jestli je verifikovaná vlastnost v systému splnˇena nebo ne. Existuj´ı ale také specifikace, které ovˇeˇrit nelze.

Analýza poskytuje odpovˇedi na obecnˇejˇs´ı otázky o systému, neodpov´ıdá tedy ano/ne, zda je vlastnost v systému splnˇena, ale podává komplexnˇejˇs´ı informace o chován´ı systému jako optimalizace, syntéza, apod.

Rozd´ıl mezi formáln´ımi metodami a testován´ım spoˇc´ıvá v odpovˇedi na otázku, zda systém obsahuje danou chybu. Pokud se bˇehem testován´ı objev´ı chyba, je zˇrejmé, ˇze pro-gram danou chybu obsahuje, ale pokud se bˇehem testován´ı chyba neprojev´ı, neznamená to, ˇze v programu zadaná chyba nen´ı. Narozd´ıl od formáln´ı verifikace, jestliˇze se bˇehem

(12)

verifikace chyba neprojev´ı a byla provedena verifikace celého systému, uvedená chyba se v systému opravdu nevyskytuje.

Ideáln´ı formáln´ı verifikace splˇnuje následuj´ıc´ı vlastnosti. Ideáln´ı formáln´ı verifikace je plnˇe automatická, spolehlivá (pokud dojde k závˇeru, mus´ı být správný), úplná (pokud najde chybu, jedná se o skuteˇcnou chybu – nejede o false alarm), koneˇcná (verifikace vˇzdy skonˇc´ı s urˇcitým závˇerem). Bohuˇzel v praxi ideáln´ı verifikace neexistuje, kritickým problémem ve-rifikace je stavová exploze. V pˇripadˇe systému s koneˇcným stavovým prostorem a moˇznost´ı vyuˇz´ıt´ı dostateˇcnˇe výkonného poˇc´ıtaˇce – verifikace vˇzdy dojde k závˇeru. V praxi se ale ˇcasto setkáváme s neomezeným stavovým prostorem nebo nadmˇernými poˇzadavky na výkon poˇc´ıtaˇce (d˚uvodem je práce s daty – jeden tˇricetidvou-bitový integer m˚uˇze nabývat 232 hod-not, paralelismus, nedeterminismus, ...).

Reálné verifikace maj´ı tedy následuj´ıc´ı vlastnosti: produkuj´ı false alarmy, nekonˇc´ı vˇzdy korektnˇe, nejsou plnˇe automatické a nejsou stoprocetnˇe spolehlivé.

K tomu, aby bylo moˇzné provádˇet verifikace, je nejprve zapotˇreb´ı nadefinovat systém, který bude verifikován a jeho vlastnosti, které se maj´ı zkontrolovat. Vstupn´ı systém m˚uˇze být popsán pomoc´ı modelu (petri net, promela, SMV, atd.) nebo jako reálný systém (pro-gramy v r˚uzných programovac´ıch jazyc´ıch, Verilog, hardware pospaný ve VHDL, atd.). Vlastnosti, které se maj´ı verifikovat, mohou být napˇr. ˇzivost promˇenných, invarianty, ukon-ˇ

cen´ı systému pouze v poˇzadovaném m´ıstˇe. Vlastnosti, které se verifikuj´ı, lze rozdˇelit do dvou skupin: bezpeˇcnost a ˇzivost. Bezpeˇcnost nám ˇr´ıká, ˇze v systému nikdy nenastane nic ˇspatn´ e-ho, protipˇr´ıklad takové vlastnosti je koneˇcný – nˇekdy nastane nˇeco ˇspatného. Oproti tomu ˇzivost systému ˇr´ıká, ˇze v systému nˇekdy nastane nˇeco dobrého a protipˇr´ıklad je nekoneˇcný – nikdy nenastane nic ˇspatného. Lze tedy uvést, ˇze bezpeˇcnost se verifikuje snadnˇeni neˇz ˇ

zivost. Pro popis vlastnost´ı je moˇzn´e pouˇz´ıt napˇr´ıklad formule tempor´aln´ıch logik,µ-calcul, labels, atd.

Dalˇs´ı d˚uleˇzitou charakteristikou vlastnost´ı pro verifikaci je ˇcas, který má dvˇe základn´ı rozdˇelen´ı na ˇcas logický/fyzický a lineárn´ı/vˇetv´ıc´ı se. Logický ˇcas ukazuje ˇcasový sled jed-notlivých událost´ı podle bˇehu, kdeˇzto fyzický ˇcas slouˇz´ı k urˇcen´ı kolik ˇcasu na jakou událost bylo potˇreba vzhledem ke zvolenému mˇeˇr´ıtku. V lineárn´ım ˇcase je pouze jedna moˇznost ˇ

casu, je moˇzný pouze lineárn´ı bˇeh programu. Oproti tomu vˇetv´ıc´ı se ˇcas umoˇzˇnuje spoleˇcný náhled na dva bˇehy, které se rozcházej´ı aˇz posléze.

Nejpouˇz´ıvanˇejˇs´ımi metodami pro formáln´ı analýzu a verifikaci jsou model checking, sta-tická analýza a theorem proving.

Model checking. Model checking je algoritmická technika, která ovˇeˇruje, zda systém splˇnuje poˇzadované vlastnosti [4]. Verifikovaný systém m˚uˇze být popsán jak modelem, tak reálným systémem. Model checking umoˇzˇnuje verifikovat systémy s koneˇcným stavovým prostorem. Kritickým problémem model checkingu je exploze stavového prostoru, kde veli-kost stavového prostoru roste exponenciálnˇe s velikost´ı verifikovaného systému [21]. Vlast-nosti jsou typicky specifikovány pomoc´ı temporáln´ıch logik.

Výhodami model checkingu jsou: vysoký stupeˇn automatizace, snadné pouˇzit´ı (pokud to umoˇzˇnuje systém), pomˇernˇe vˇseobecné pouˇzit´ı pro verifikaci r˚uzných vlastnost´ı systému. Oproti tomu hlavn´ı nevýhodou je jiˇz zmiˇnovaná exploze stavového prostoru, který se dá ˇreˇsit r˚uznými metodami jako redukce, abstrakce, kompozice systému z ˇcást´ı, atd. Dalˇs´ı nevýhodou je nutnost modelovat okol´ı verifikovaného systému jako jsou vstupy.

Statická analýza. Statická analýza se neprovád´ı nad skuteˇcným bˇehem systému, ale pouze nad zdrojovým kódem. T´ım umoˇzˇnuje zjistit informace o programu ze zdrojového kódu, aniˇz by bylo nutné program spouˇstˇet. Statické analýzy jsou r˚uzné druhy (typová

(13)

analýza, vyhledáván´ı chybových vzor˚u – bug pattern, dataflow analýza, apod.). Výhodami statické analýzy je moˇznost verifikovat obrovské systémy, zároveˇn nen´ı nutné modelovat okol´ı systému a nab´ız´ı velký stupeˇn automatizace. Nevýhodou je velká specializace jednot-livých statických analýz na konkrétn´ı problémy. Pokud je c´ılem zverifikovat novˇe zadaný problém, mus´ı se nejprve navrhnout nová statická analýza pro jeho ovˇeˇren´ı. Dalˇs´ı nevýhodou je vznik false alarm˚u. D´ıky tomu, ˇze se statická analýza provád´ı nad zdrojovým kódem, m˚uˇze nadetekovat chybu, která pˇri skuteˇcném bˇehu nikdy nenastane (false positive).

Theorem proving. Jedná se o deduktivn´ı verifikaci, která vycház´ı z axiom˚u a po-moc´ı pouˇzit´ı r˚uzných pravidel produkuje vlastnosti systému. Uˇzit´ı jednotlivých pravidel nen´ı automatické, je potˇreba zásahu uˇzivatele

”experta“, který vede d˚ukaz. Jedná se tedy o ˇcásteˇcnˇe automatickou metodu, která je velmi obecná, coˇz je jej´ı výhodou. Nevýhodou je problém s diagnostickou informac´ı, která m˚uˇze, ale také nemus´ı být k dispozici.

Pro ovˇeˇren´ı opravy byla zvolena fromáln´ı metoda – model checking. Ta umoˇzˇnuje verifi-kovat systém dynamicky, a tedy hledat pouze chyby, které mohou v systému reálnˇe nastat oproti statické analýze, která produkuje hodnˇe false alarm˚u. Dalˇs´ı výhodou je ˇsiroký výbˇer z exituj´ıc´ıch nástroj˚u (model checker˚u) pro verifikaci pomoc´ı model checkingu.

(14)

Kapitola 3

Model Checking

Model checking je algoritmická cesta k ovˇeˇren´ı, zda zadaný systém splˇnuje poˇzadovanou vlastnost [4]. Základn´ı schéma verifikaˇcn´ıho procesu je znázornˇené na obr. 3.1. Vstupem pro verifikace je verifikovaný systém, který je typicky popsán pomoc´ı formáln´ıho modelu systému. Druhým vstupem je formáln´ı specifikace vlastnost´ı, které se maj´ı ovˇeˇrit. Model systému a specifikované vlastnosti vstupuj´ı do model checkeru, který ovˇeˇruje resp. verifikuje zadané vlastnosti. V ideáln´ım pˇr´ıpadˇe nám model checker vrát´ı odpovˇed’ ano/ne, podle toho jestli je vlastnost splnˇena. V praxi ovˇsem m˚uˇze nastat i situace, kdy nám model checker nen´ı schopen poskytnout odpovˇed’, napˇr. z d˚uvodu nedostatku pamˇeti.

Obrázek 3.1: Základn´ı schéma procesu verifikace pomoc´ı model checkeru

Principem model checkingu je systematické prohledáván´ı stavového prostoru. Stav (state) je sn´ımek systému v ˇcase, zachycuje hodnoty promˇenných v daném ˇcasovém okamˇziku. Zároveˇn chceme znát, jak se stavy mˇen´ı– popis zmˇeny mezi jednotlivými stavy (stav pˇred událost´ı a stav po události) se nazývá pˇrechod (transition). Výpoˇcet (computation) je sek-vence stav˚u, kde se následuj´ıc´ı stav z´ıská z pˇredchoz´ıho stavu pomoc´ı pˇrechodu.

(15)

3.1 Model syst´

emu

Reálné systémy jsou vˇetˇsinou zadány pomoc´ı textu programu (zdrojový kód) nebo diagra-mem cest. Je tedy potˇreba mechanizmus, který je schopen popsat vˇsechny typy systém˚u tak, aby mohli být verifikovány. Jednou moˇznost´ı popisu chován´ı systému je Kripkeho struk-tura (Kripke structure) obr. 3.2(a) . Jedná se o graf, který popisuje stavy systému a jeho pˇrechody:

Necht’ AP je mnoˇzina atomick´ych v´yrok˚u, pak Kripkeho struktura M nad AP je ˇctveˇrice M = (S, S0, R, L), kde

• S je mnoˇzina stav˚u,

• S0 ⊆ S je mnoˇzina poˇc´ateˇcn´ıch stav˚u,

• R ⊆ S × S je pˇrechodov´a relace mezi stavy takov´a, ˇze ∀s ∈ S : ∃s0 ∈ S : R(s, s0) • L : S → 2AP _{je funkce pˇ}_riˇ_{razuj´ıc´ı kaˇ}_zd´_{emu stavu mnoˇ}_{zinu vˇ}_{sech atomick´}_{ych tvrzen´ı,}

která v daném stavu plat´ı, AP = {v = d | v ∈ V ∧ d ∈ D}, kde V je mnoˇzina promˇenných nad doménou D.

Pro popis sekvenˇcn´ıho chován´ı Kripkeho struktury M jsou definovány cesty (paths). Cesta (path) v Kripkeho struktuˇre M ze stavu s je nekoneˇcná sekvence stav˚u π = s0s1s2...,

která je ˇrazená s ohledem na pˇrechodovou relaci v M . Pˇrechodová relace R(si, si+1) plat´ı

pro vˇsechny 0 ≤ i < |π| − 1. Jestliˇze I(s0) t.j. s0 je poˇcáteˇcn´ı stav, potom se cesta nazývá

poˇcáteˇcn´ı (initialized). Délka cesty (length) |π| m˚uˇze být jak koneˇcná, tak nekoneˇcná. Pro i < |π| je definovaný i-tý stav si v sekvenci jako π(i). Suffixem π je πi = (si, si+1, . . . ),

který zaˇc´ıná stavem si. Vˇsechny moˇzné poˇcáteˇcn´ı cesty systému, lze z Kripkeho struktury

zapsat pomoc´ı výpoˇcetn´ıho stromu (computation tree) obr. 3.2(b). Výpoˇcetn´ı strom tedy vznikne rozepsán´ım Kripkeho struktury z poˇcáteˇcn´ıho stavu.

Obrázek 3.2: Ukázka Kripkeho struktury (a) a výpoˇcetn´ıho stromu (b)

Granularita pˇrechod˚u. Jedn´ım ze zásadn´ıch nastaven´ı verifikace je urˇcen´ı granu-larity pˇrechod˚u systému. Tento fakt je podstatný pro urˇcen´ı atomických pˇrechod˚u, tyto

(16)

pˇrechody jsou dále nedˇelitelný. Pokud pˇrechod obsahuje v´ıce operac´ı, provádˇej´ı se jako jedna jediná atomická operace. Bˇeˇznou chybou je nastaven´ı hrubé granularity, kdy se za ato-mické pˇrechody povaˇzuj´ı i takové pˇrechody, které v reálném systému atomické nejsou. T´ım m˚uˇze doj´ıt k chybˇe pˇri verifikaci, model checking neodhal´ı chyby (errors), které v systému jsou. Oproti tomu nastaven´ı velmi jemné granularity m˚uˇze zp˚usobit detekován´ı chyb, které v reálném bˇehu systému nemohou nikdy nastat.

Pˇr´ıklad z [4]: Systém má 2 promˇenné x, y a dva soubˇeˇznˇe proveditelné pˇrechody α, β. α : x := x + y

β : y := y + x

s poˇcáteˇcn´ım stavem x = 1, y = 2. Oba pˇrechody maj´ı jemnou granularitu, implementace pˇrechod˚u je pomoc´ı instrukc´ı assembleru: load, add, store, které slouˇz´ı pro práci s pamˇet´ı a registry:

α0: load R1, x β0: load R2, y

α0: add R1, y β0: add R2, x

α0: store R1, x β0 : store R2, y

Výpoˇcet pˇrechodu α a pak β dává výsledek x = 3 ∧ y = 5. Pokud je pˇrechod β vykonán pˇred α obdrˇz´ıme výsledek x = 4 ∧ y = 3. Na druhou stranu podle granularity implementace m˚uˇze nastat i situace α0β0α1β1α2β2 a výsledek x = 3 ∧ y = 3.

Pˇredpokládejme, ˇze x = 3 ∧ y = 3 poruˇsuje vlastnosti systému, dále pˇredpokládejme, ˇ

ze systém je implementován pro pˇrechod α a β. V tom pˇr´ıpadˇe je nemoˇzné z´ıskat výsledek x = 3 ∧ y = 3. Potom s granularitou α0α1α2β0β1β2 m˚uˇzeme dostat stavy, které v systému

nikdy nenastanou. Na druhou stranu m´ame implementaci α0α1α2β0β1β2, ale syst´em

mo-delujeme s α a β, potom nikdy nenalezneme chybu v syst´emu.

Systémy se soubˇeˇznost´ı. Takové systémy se skládaj´ı z mnoˇziny komponent, které bˇeˇz´ı souˇcasnˇe. Jednotlivé komponenty si mezi sebou pˇredávaj´ı r˚uzná data – komunikuj´ı. Zp˚usob komunikace je v jednotlivých systémech r˚uzný. Komunikace m˚uˇze prob´ıhat asyn-chronnˇe – v ˇcasovém okamˇziku pracuje pouze jedna komponenta, nebo synchronnˇe – vˇsechny komponenty dˇelaj´ı krok ve stejném ˇcase. Komunikace prob´ıhá za pomoci sd´ılených promˇ en-ných (shared variables) nebo zas´ılán´ı zpráv (exchanging messages). Pokud program obsa-huje sd´ılené promˇenné resp. promˇenné, ke kterým má pˇr´ıstup v´ıce neˇz jeden proces, je tˇreba zajistit, aby ke sd´ılené promˇenné mˇel v daný ˇcasový okamˇzik pˇr´ıstup pouze jeden proces. V opaˇcném pˇr´ıpadˇe m˚uˇze doj´ıt k nekonzistenci dat. Pro tyto úˇcely slouˇz´ı synchronizaˇcn´ı pˇr´ıkazy, které jsou atomické a mohou m´ıt podobu pˇr´ıznaku ˇcekán´ı (wait) nebo zámk˚u (lock/unlock).

3.2 Specifikace syst´

emu

Po formáln´ım nadefinován´ı systému je tˇreba také formálnˇe nadefinovat vlastnosti, které se maj´ı verifikovat. Typickou formou specifikace vlastnost´ı pro model checking jsou následuj´ıc´ı temporáln´ı logiky:Linear-time Temporal Logic (LTL), Computation Tree Logic (CTL) a CTL∗, která spojuje vyjadˇrovac´ı moˇznosti LTL a CTL.

Temporáln´ı logiky jsou speciáln´ım typem modáln´ıch logik, pomoc´ı nichˇz se daj´ı nade-finovat formule, které vyajdˇruj´ı urˇcitou vlastnost systému. V temporáln´ı logice nen´ı ˇcas uveden explicitnˇe, naopak, formule umoˇzˇnuj´ı urˇcit, zda je nˇejaký stav proveditelný nebo tento stav nikdy nenastane (napˇr. chybový stav), jedná se o logický ˇcas. Vlastnosti typu nˇekdy (sometimes) nebo nikdy (never) jsou popsány speciáln´ımi temporáln´ımi operátory. Temporáln´ı operátory mohou být kombinovány libovolnˇe s booleovskými spojkami nebo

(17)

vzájemnˇe vnoˇreny. Jednotlivé temporáln´ı logiky se liˇs´ı v operátorech, které poskytuj´ı a také v jejich sémantice.

Logika CTL∗. Tato logika zahrnuje v sobˇe logiky CTL a LTL. CT L∗ formule popisuj´ı vlastnosti výpoˇcetn´ıch strom˚u. CT L∗ formule obsahuje: atomické výroky (AP), booleovské spojky (∧, ∨, ¬), kvantifikátory cesty, temporáln´ı operátory.

Kvantifik´atory cesty jsou pouˇzity pro popis vˇetven´ı ve v´ypoˇcetn´ım stromu: • A pro vˇsechny cesty

• E existuje cesta

Temporáln´ı operátory popisuj´ı vlastnosti cesty (cesty pˇres strom). Existuje pˇet základn´ıch temporáln´ıch operátor˚u:

• Xp (next time) vlastnost p bude splnˇena v následuj´ıc´ım stavu dané cesty, • Fp (eventually) vlastnost p bude splnˇena nˇekdy na dané cestˇe,

• Gp (globally) vlastnost p je splnˇena ve vˇsech stavech dan´e cesty, • pUq (until) vlastnost p plat´ı na cestˇe dokud neplat´ı q,

• pRq (release) vlastnost q byla splnˇena ve vˇsech stavech cesty aˇz po prvn´ı stav vˇcetnˇe, ve kter´em plat´ı formule p.

V CT L∗ logice existuj´ı dva typy formul´ı stavov´e formule (state formulas) a formule cesty (path formulas).

Logika CTL a LTL. Jsou podlogiky CT L∗, rozd´ıl mezi nimi je v upoˇrádán´ı vˇetven´ı ve výpoˇcetn´ım stromu. CTL (Computation Tree Logic) je logika s vˇetv´ıc´ım se ˇcasem a temporáln´ı operátory urˇcuj´ı cesty, které jsou moˇzné z daného stavu obr. 3.3(b). Oproti tomu LTL (Linear Temporal Logic) je logika s lineárn´ım ˇcasem a operátory urˇcuj´ı události, které mohou nastat po cestˇe ve výpoˇcetn´ım stromu obr. 3.3(a).

(18)

3.3 V´

ystup verifikace

Výsledkem verifikace je tedy odpovˇed’ na otázku model checkingu: Necht’, je dána Kripkeho struktura M = (S, S0, R, L), pomoc´ı které je popsán verifikovaný systém a temporáln´ı

formule f , reprezentuj´ıc´ı poˇzadovanou vlastnost, kterou má systém splˇnovat. Odpovˇed´ı model checkingu je, zda zadaná formule f je splnˇena v Kripkeho struktuˇre M :

M |= ϕ ?,

respektive urˇcit mnoˇzinu stav˚u syst´emu S, ve kter´ych je formule f splnˇena: {s ∈ S | M, s |= ϕ}.

Postup urˇcen´ı, zda je formule f plnˇena spoˇc´ıv´a v ovˇeˇren´ı, ˇze: • pro kaˇzdou podformuli ψ formule ϕ je vypoˇctena mnoˇzina stav˚u:

Sψ = {s ∈ S | M, s |= ψ},

• výpoˇcet mnoˇziny stav˚u Sψ zaˇc´ıná u nejvnitˇrenjˇs´ıch (dále nedˇelitelných) podformul´ı a

postupuje se smˇerem ven k z´ısk´an´ı mnoˇziny stav˚u p˚uvodn´ı formule ϕ.

Typicky se provád´ı model checking z poˇcáteˇcn´ıho stavu (stav˚u) systému, d´ıky tomu se ovˇeˇr´ı, zda je specifikace splnˇena v celém systému (S0 ⊆ Sϕ) nebo jeho ˇcásti – formule je

splnˇena v poˇzadovan´ych stavech.

Existuj´ı r˚uzné algoritmy, pomoc´ı nichˇz se urˇcuj´ı mnoˇziny stav˚u, ve kterých je poˇzadovaná formule splnˇena. Nicménˇe pro výpoˇcet mnoˇziny u r˚uzných formul´ı, které obsahuj´ı jiné tem-poráln´ı operátory je tˇreba aplikovat r˚uzné algoritmy, jednotlivé algoritmy lze naj´ıt napˇr´ıklad v [4].

Algoritmy pro ovˇeˇren´ı formule jsou zaloˇzeny na procházen´ı stavovým prostorem a jejich hlavn´ım problém se tedy stává exploze stavového prostoru.

3.4 Probl´

em stavov´

e exploze

Exploze stavového prostoru je kritickým problémem model checkingu (state space explo-sion problem), kde verifikace spoˇc´ıvá v generován´ı stavového prostoru. Velikost stavového prostoru roste exponenciálnˇe s velikost´ı verifikovaného modelu resp. systému [21]. Z toho d˚uvodu je prakticky model checking bez redukce stavového prostoru v praxi nepouˇzitelný. Exploze stavového prostoru spoˇc´ıvá v nedeterminismu – ve velkém mnoˇzstv´ı moˇznost´ı stav˚u, kterými m˚uˇze systém pokraˇcovat z aktuáln´ıho stavu. Pro ˇreˇsen´ı problému stavové exploze existuj´ı r˚uzné pˇr´ıstupy [7,15,21,23]. Jedn´ım z moˇzných dˇelen´ı tˇechto pˇr´ıstup˚u je následuj´ıc´ı: • Pˇredzpracován´ı (preprocessing). Jeˇstˇe pˇred zaˇcátkem provádˇen´ı model checkingu se vykoná pˇredzpracován´ı verifikovaného systému. Do této skupiny patˇr´ı: slicing a jemu podobné techniky zaloˇzené na statické analýze, jejich podstatou je

”oˇr´ıznut´ı“ ve-rifikovaného systému pouze na tu ˇcást, která m˚uˇze ovlivnit verifikovanou vlastnost. Vlastn´ı model checking se provád´ı pouze nad

”oˇr´ıznutou“ ˇcást´ı systému. Dalˇs´ı meto-dou je nad aproximace, pomoc´ı n´ı je moˇzné zjistit, co ovlivˇnuje zkoumanou oblast a dále pracovat se zvolenou ˇcást´ı systému. Dále je moˇzné pouˇz´ıt explicitn´ı urˇcen´ı ato-mické sekce. Uˇzivatel sám zadá oblasti, které maj´ı být vykonány atomicky a nemá se rozgenerovávat jejich stavový prostor. V tom pˇr´ıpadˇe sám uˇzivatel zaruˇcuje, ˇze j´ım zadaná atomická sekce nezp˚usob´ı nenalezen´ı chyby. Existuj´ı i metody, které dokáˇz´ı urˇcit atomické sekce automaticky. Tyto sekce jsou ovˇsem vˇetˇsinou velice jednoduché a

(19)

neefektivn´ı vzhledem k redukci stavového prostoru. Dalˇs´ı moˇznost´ı je abstrakce (abs-traction). Abstrakce se m˚uˇze vytvoˇrit bud’ ruˇcnˇe (theorem proving, uˇzivatel) nebo automaticky (predikátová abstrakce, petriho s´ıtˇe).

• Efektivn´ı uloˇzen´ı Kripkeho struktury v pamˇeti. Dalˇs´ı moˇznost´ı jak se vypoˇrádat se stavovou exploz´ı je komprimace stavového prostoru. BDD (binary decision diagram) je jednou z moˇznost´ı jak komprimovat stavový prostor, jednotlivé stavy jsou reprezen-továny pomoc´ı formul´ı. Dalˇs´ı moˇznost´ı je efektivn´ı uloˇzen´ı stavu v pamˇeti, neukládaj´ı se celé novˇe generované stavy, ale pouze zmˇeny mezi jiˇz uloˇzeným stavem a novˇe generovaným. Abstrakce stav˚u je metoda, která redukuje informace o procesech. Ne-uchovává se informace o pˇresném poˇctu proces˚u, ale pouze informace zda na daném ˇrádku kódu je 0, 1 nebo ∞ proces˚u, jedná se o nadaproximaci.

• Redukce stavového prostoru. Redukce stavového prostoru neznamená pouze efek-tivn´ı procházen´ı stavového prostoru, ale také redukce poˇctu stav˚u. Redukce stav˚u m˚uˇze prob´ıhat bud’ pˇredem nebo za bˇehu programu – nˇekteré generované stavy nejsou z hlediska verifikované vlastnosti zaj´ımavé. Metody pro redukci stavového prostoru jsou: symmetry reduction, Petri-net unifolding (rozvinut´ı petriho s´ıtˇe do lineárn´ıho stromu).

Zaj´ımav´e redukce pro programy se soubˇeˇznost´ı jsou

”Partial order reduction“ (POR) a

”on-the-fly model checking“. POR je zaloˇzená na redukován´ı generován´ı stavového prostoru. V programech existuj´ı nezávislé pˇrechody u kterých nezáleˇz´ı na poˇrad´ı je-jich vykonán´ı, po jejich proveden´ı se verifikace dostává do shodného stavu. Takové pˇrechody (operace) se typicky vyskytuj´ı u v´ıce vláknových aplikac´ı, kdy r˚uzná válkna provád´ı na sobˇe nezávislé operace a nezáleˇz´ı tedy na poˇrad´ı jejich provádˇen´ı. Ukázka ˇcásti vygenerovaného stavového prostoru, kde je moˇzné tuto generovanou ˇcást redu-kovat pouze na proveden´ı jednoho pr˚uchodu je na obr.3.4.

Obrázek 3.4: Ukázka redukce stavového prostoru pomoc´ı POR

Metoda on-the-fly je zaloˇzena na souˇcasném generován´ı stavového prostoru a ovˇeˇrován´ı vlastnosti systému najednou. Pˇri generován´ı stavového prostoru se souˇcasnˇe verifi-kuje, zda je vlastnost v daném generovaném stavu splnˇena. Pokud dojde k nalezen´ı protipˇr´ıkladu verifikované vlastnosti, generován´ı stavového prostoru konˇc´ı. Verifikace dospˇela k závˇeru bez nutnosti rozgenerovávávat celý stavový prostor a t´ım k jeho redukci.

(20)

• Kompoziˇcn´ı model checking (Compositional of MC). Jedná se o rozdˇelen´ı systému na komponenty, kde u kaˇzdé komponenty sledujeme urˇcité vlastnosti. Nako-nec z tˇechto d´ılˇc´ıch vlastnost´ı komponent odvod´ı vlastnosti celého systému.

Existuj´ı i dalˇs´ı metody pro redukci stavového prostoru, které zde nejsou uvedeny. Také je moˇzné jednotlivé metody vhodným zp˚usobem kombinovat, a t´ım doc´ılit vyˇsˇs´ı efektivnosti pˇri redukci stavového prostoru.

3.5 Bounded Model Checking

Bounded model checking resp. ohraniˇcený model checking se pouˇz´ıvá pro verifikaci koneˇcnˇe stavových systém˚u. Bounded model checking m˚uˇze úˇcinnˇe redukovat problém splnitelnosti booleovské formule – SAT . Tento problém byl jedn´ım z d˚uvod˚u pro vytvoˇren´ı této me-tody [3].

Základn´ı myˇslenkou bounded model checkingu je ovˇeˇren´ı urˇcité vlastnosti systému pouze za pomoci koneˇcného prefixu cesty v systému. Nalezen´ı d˚ukazu o splnˇen´ı nebo vyvrácen´ı urˇcité vlastnosti systému se provád´ı v koneˇcném poˇctu krok˚u. Prohledáván´ı stavového systému je omezeno na pˇredem danou délku k. Pomoc´ı omezen´ı prohledáván´ı stavového systému se omez´ı i verifikace poˇzadované vlastnosti. Verifikace je omezena na verifikaci pre-fixu cesty, která má délku k. V praxi se vˇetˇsinou omezená délka cesty prodluˇzuje na takovou dobu, dokud se nez´ıská d˚ukaz o splnˇen´ı/vyvrácen´ı verifikované vlastnosti.

Pˇrestoˇze prefix cesty je koneˇcný – obsahuje koneˇcný poˇcet stav˚u, m˚uˇze reprezentovat nekoneˇcnou cestu. Pokud cesta obsahuje zpˇetnou smyˇcku (back loop) z posledn´ıho stavu prefixu do nˇekterého z pˇredchoz´ıch stav˚u (obr. 3.5(b)) jedná se o reprezentaci nekoneˇcné cesty pomoc´ı koneˇcného poˇctu stav˚u. V pˇr´ıpadˇe, ˇze prefix cesty neobsahuje zpˇetnou smyˇcku (obr. 3.5(a)), nelze ˇr´ıci nic o nekoneˇcném chován´ı systému. Nelze zverifikovat vlastnosti, které poˇzaduj´ı, aby urˇcitá vlastnost byla platná nekonˇcnˇe dlouho. Pokud prefix neobsahuje zpˇetnou smyˇcku nen´ı známé chován´ı systému za stavem sk.

Obrázek 3.5: Dvˇe moˇznosti omezené cesty Definice pro cestu, která obsahuje zpˇetnou smyˇcku je následuj´ıc´ı:

Pro l ≤ k nazýváme cestu π: (k, l)-loop, pokud T (π(k), π(l)) a π = u.vω, kde u = (π(0), . . . , π(l − 1)) a v = (π(l), . . . , π(k)). Pokud existuje k≥l≥0, pro které je cesta π: (k, l)-loop, pak nazýváme cestu π: k-loop.

Pokud na cestˇe d´elky k existuje pˇrechod z posledn´ıho stavu cesty sk do nˇekter´eho

z pˇredeˇslých stav˚u cesty sl, pak je moˇzné danou ˇcást cesty neomezenˇe krát opakovat k-loop.

Sémantika model checkingu na limitovaných cestách se nazývá bounded semantics. Vyu-ˇ

z´ıvá se prvn´ıch k + 1 stav˚u cesty (s0, . . . , sk), jedná se o koneˇcný prefix cesty. Pomoc´ı tohoto

prefixu se urˇcuje splnitelnost formule na cestˇe. Pokud cesta obsahuje smyˇcku k-loop, m˚uˇze se pro splnitelnost formule pouˇz´ıt origináln´ı sémantika model checkingu. Tato sémantika lze vyuˇz´ıt vzhledem k faktu, ˇze pokud cesta obsahuje zpˇetnou smyˇcku jsou nekoneˇcné vlastnosti

(21)

cesty obsaˇzeny v jej´ım koneˇcn´em prefixu. Form´alnˇe lze toto tvrzen´ı

”Bounded Semantics for a Loop“ zapsat n´asledovnˇe:

Necht’ k ≥ 0 a π je k-loop. Potom LT L formule f je splnˇena na cestˇe π délky k (sym-bolický zápis π |=k f iff π |= f ).

Druhá moˇznost nastává v pˇr´ıpadˇe, kdy cesta π neobsahuje k-loop. Potom formule f = Fp je splnˇena na cestˇe π v origináln´ı (neomezené) sémantice, jestliˇze existuje index i ≥ 0, takový, kde p je splnˇena na sufixu (πi) cesty π. Pokud je pouˇzita omezená sémantika,

potom k+1-n´ı stav π(k) nemá následovn´ıka a nen´ı tedy moˇzné tuto sémantiku definovat rekurzivnˇe pomoc´ı sufix˚u cesty (πi). Z toho d˚uvodu se zavád´ı znaˇcen´ı π |=ik f , kde i je

aktu´aln´ı pozice v prefixu na cestˇe π a suffix πi cesty π splˇnuje formuli f : π |=ikf implikuje

πi |= f . Form´aln´ı definice tohoto tvrzen´ı_”Bounded Semantics without a Loop“ lze zapsat

n´asledovnˇe:

Necht’ k ≥ 0, cesta π nen´ı k-loop. Potom LT L formule f je splnˇena na cestˇe π d´elky k resp. π |=kf iff π |=0_kf , kde

π |=i_kGf nen´ı splnˇena nikdy

π |=i_kFf iff ∃j, i ≤ j ≤ k. π |=j_kf π |=i_kXf iff i < k and π |=i+1_k f

Na závˇer této kapitoly o bounded model checkingu zle uvést následuj´ıc´ı dvˇe vˇety: Necht’ f je LT L formule a π je cesta, potom π |=k f ⇒ π |= f .

Necht’ f je LT L formule a M je Kripkeho struktura. Jestliˇze M |= Ef , potom existuje k ≥ 0, kde M |=kEf .

Z tˇechto dvou vˇet lze odvodit n´asleduj´ıc´ı theor´em o bounded model checkingu:

Necht’ f je LT L formule a M je Kripkeho struktura, potom M |= Ef iff existuje k ≥ 0, resp. M |=kEf .

Theorém ˇr´ıká, pokud zle z´ıskat takovou délku k, na které je formule splnˇena, potom omezená a neomezená sémantika jsou ekvivalentn´ı.

3.6 Navigace stavov´

ym prostorem

V projektu SHADOWS se bounded model checking vyuˇz´ıvá pro zverifikován´ı okol´ı léˇcené chyby, nen´ı tedy c´ılem provést bounded model checking z poˇcáteˇcn´ıho stavu (s0), ale

z nˇejakého konkrétn´ıho stavu ve stavovém prostoru systému. Aby bylo moˇzné z toho stavu provést bounded model checking, je potˇreba nejprve daného stavu dosáhnout, proj´ıt sta-vový prostor do konkrétn´ıho stavu. K tomuto úˇcelu existuj´ı r˚uzné metody [14, 20], které slouˇz´ı k navigaci stavovým prostorem do poˇzadovaného stavu. Tyto metody mohou být následuj´ıc´ı.

• Record&Replay trace. Tato strategie pro navigaci stavovým prostorem je zaloˇzena na zaznamenán´ı bˇehu programu (trace) a posléze pˇrehrán´ı této cesty ve zvoleném

(22)

model checkeru. Pomoc´ı záznamu bˇehu programu se je moˇzné navádˇet stavovým prostorem aˇz do m´ısta opravy chyby, ze kterého je moˇzné spustit bounded model checking. Výhodou této metody je zaznamenán´ı celé cesty provádˇen´ı programu. D´ıky tomu je moˇzné provést bounded model checking ne pouze z chybového stavu pro-gramu, ale z kteréhokoliv stavu, který mu na cestˇe pˇredcház´ı. Zásadn´ı nevýhodou této metody je nutnost ukládán´ı celého bˇehu programu, a t´ım zpomalen´ı chodu apli-kace. Dalˇs´ı nevýhodou je pamˇet’ová nároˇcnost, pro záznam cesty programu je za-potˇreb´ı velké mnoˇzstv´ı dat. ˇC´ım delˇs´ı dobu program bˇeˇz´ı, t´ım je potˇreba v´ıce pamˇeti pro záznam cesty. Minimálnˇe stejnˇe dlouhá doba jako pro záznam cesty je také potˇreba pro pˇrehrán´ı zaznamenané cesty. Proto se tato metoda nehod´ı pro navigaci stavovým prostorem u systém˚u, které jsou dlouhodobˇe v chodu.

Aby bylo moˇzné pˇrehrát zaznamenanou cestu bˇehu programu, je tˇreba ukládat re-levantn´ı informace jako informace o aktuáln´ım vláknˇe, vykonané byte-code instrukci atd.

• Store&Restore state. Dalˇs´ı strategie pro z´ıskán´ı poˇzadovaného stavu ze stavového prostoru systému je zaloˇzena na uloˇzen´ı a opˇetovném obnoven´ı stavu. Neprve se uloˇz´ı aktuáln´ı stav bˇeˇz´ıc´ıho programu a následnˇe se uloˇzený stav obnov´ı ve zvoleném model checkeru. Po obnoven´ı uloˇzeného stavu je z nˇej moˇzné provést bounded model chec-king. Nevýhodou této metody je nemoˇznost zaˇc´ıt bounded model checking z jiného neˇz z pouze uloˇzeného stavu. Nen´ı moˇzné jako u pˇredeˇslé metody zahájit bounded model checking z nˇejakého z pˇredcházej´ıc´ıch stav˚u bˇehu programu. Dalˇs´ı nevýhodou je slabost v ukládán´ı stavu. Pokud dojde ke zmˇenˇe v uloˇzeném stavu je tˇreba provést pˇr´ısluˇsnou zmˇenu i v ukládaném resp. obnoveném stavu. Napˇr. u Java program˚u m˚uˇze doj´ıt ke zmˇenˇe verze Java virtáln´ıho stroje (JVM) nebo zmˇena verze model checkeru m˚uˇze zp˚usobit také nutnost zmˇeny v ukládán´ı a obnoven´ı stavu. Nevýhoda moˇznosti verifikace pouze z uloˇzeného stavu se dá ˇcásteˇcnˇe odstranit opˇetovným ukládán´ım stav˚u systému napˇr. po urˇcitém ˇcasovém intervalu. Nicménˇe stále tu z˚ustává nutnost uloˇzen´ı veˇskerých potˇrebných informac´ı pro obnoven´ı stavu systému v model chec-keru. Tˇechto informac´ı je znaˇcná spousta a jak jiˇz bylo zm´ınˇeno, s kaˇzdou zmˇenou verze m˚uˇze doj´ıt k nutnosti zmˇenˇe ukládaných informac´ı. Naopak výhodou je fakt, ˇze nezp˚usobuje trvalé zpomalen´ı bˇehu programu, ke zpomalen´ı docház´ı pouze v dobˇe ukládán´ı stavu.

• Dalˇs´ı Strategie. Výˇse uvedené strategie se daj´ı r˚uznˇe kombinovat, napˇr. po urˇcitém ˇcasovém intervalu m˚uˇze docházek k ukládán´ı stavu systému a zaznamenáván´ı cesty z tohoto stavu. Po urˇcité dobˇe dojde k pˇremazán´ı uloˇzené cesty a stavu novými in-formacemi.

Dalˇs´ı moˇznost´ı je modifikace uveden´ych strategi´ı, jako napˇr´ıklad Record&Replay trace lze kombinovat s

”oˇrezáván´ım (slicing)“. Jedná se o metodu, pomoc´ı které se ne-ukládaj´ı vˇsechny informace o bˇehu programu, ale pouze ty informace, které jsou rele-vantn´ı k pˇrehrán´ı bˇehu programu do poˇzadovaného stavu.

(23)

Kapitola 4

Java PathFinder

Projekt SHADOWS se vˇenuje léˇcen´ı program˚u napsaných v jazyce Java, a proto bylo vyb´ıráno z model checker˚u vhodných pro verifikaci Java program˚u. Byly zkoumány vlast-nosti tˇechto tˇr´ı známých a zaj´ımavých model checker˚u.

• Bogor [10] je softwarový model checking framework, který poskytuje vizualizaci, grafické uˇzivatelské rozhran´ı, a také r˚uzné algoritmy po model checking (pro redukci stavového prostoru, vyhledávac´ı heuristiky, abstraktn´ı definice atd.). Bogor lze pouˇz´ıt i jako plugin do Eclipse. (Eclipse je integrované vývojové prostˇred´ı pro programován´ı Java program˚u, jeho návrh umoˇznuje rozˇs´ıˇren´ı prostˇred´ı pomoc´ı plugin˚u [2].) Jedn´ım z moˇzných vyuˇzit´ı Bogoru, je pro studijn´ı úˇcely. Je moˇzné ho vyuˇz´ıt pro výuku základn´ıch algoritm˚u model checkingu a jeho podstaty. Zároveˇn lze Bogor vyuˇz´ıt pro klasický model checking.

• Bandera [8] je model checker pro programy napsané v Javˇe, které obsahuj´ı parale-lismus. Bandera pˇrekládá zdrojový kód v Jave do vstupn´ıho jazyka nˇejakého jiného existuj´ıc´ıho model checkeru jako napˇr´ıklad SPIN, SMV, SAL, atd. Tyto jiné model checkery zabezpeˇcuj´ı vlastn´ı verifikaci systému. Po zverifikován´ı systému Bandera umoˇzˇnuje namapovat výstup verifikace ze zvoleného model checkeru na p˚uvodn´ı Java kód.

• Java PathFinder(JPF) [9] je model checker, který provád´ı verifikaci nad Java byte-codem. JPF je implementován jako speciáln´ı Java virtuáln´ı stroj (JVM), který v sobˇe pˇrehrává programy urˇcené k verifikaci. Bˇehem pˇrehráván´ı programu kontroluje poˇzadované vlastnosti nebo specifikace systému. JPF je implicitnˇe nastaven na detekci deadlocks, unhandled exception, violations of assertions. Zároveˇn JPF m˚uˇze detekovat i dalˇs´ı vlastnosti systému, které se daj´ı zadat pomoc´ı parametr˚u. Nebo je moˇzné naim-plementovat dalˇs´ı vlastn´ı speciáln´ı souˇcásti JPF pro verifikaci poˇzadovaných vlastnost´ı systému.

Pro vlastn´ı implementaci bounded model checkingu byl zvolen model checker Java PathFinder pro jeho snadnou rozˇsiˇritelnost o dalˇs´ı moduly a funkce. Java PathFinder ob-sahuje ˇradu vyhledávac´ıch strategi´ı (search strategies), redukce stavového prostoru, r˚uzné heuristiky pro prohledáván´ı stavového prostoru atd. Model checker Bogor je také moˇzné rozˇs´ıˇrit o vlastn´ı moduly, nicménˇe výhodou JPF je jeho nasazen´ı jiˇz na reálné systémy. Hlavn´ı nevýhodu model checkeru Bandera je nutnost transformovat vstupn´ı zdrojový kódu programu do jiného jazyka. T´ım je zp˚usobena nemoˇznost selodáván´ı pr˚ubˇehu verifikace nad p˚uvodn´ım Java kódem.

(24)

4.1 Z´

akladn´ı charakterisitika

Java PathFinder je explicitn´ı stavov´y model checker pro programy napsan´e v jazyce Java [9,

13, 17, 19, 22]. Verifikace se provád´ı na úrovni Java byte-codu. JPF pˇredstavuje speciáln´ı virtuáln´ı stroj, ve které se spouˇst´ı verifikovaný systém. Z d˚uvodu bˇehu aplikace pˇr´ımo v JPF, nen´ı nutné spouˇstˇet program v´ıcekrát nebo ho nˇejakým zp˚usobem upravovat. JPF neprovád´ı jednoduchý bˇeh programu, ale vykonává rovnou verifikaci za bˇehu (runtime). Prohledáván´ı stavového prostoru prob´ıhá pomoc´ı r˚uzných prohledávac´ıch strategi´ı, které budou popsány dále. Samotný Java PathFinder je také napsán v jazyce Java, jeho archi-tektura je rozdˇelena do modul˚u, které umoˇzˇnuj´ı dalˇs´ı rozˇsiˇritelnost. Je moˇzné rozˇsiˇrovat jiˇz existuj´ıc´ı moduly o dalˇs´ı funkce nebo implementovat nové moduly. Pokud JPF bˇehem ve-rifikace nalezne chybu (error), standardnˇe vyp´ıˇse cestu (trace), která k chybˇe vedla, a také vyp´ıˇse relevantn´ı informace o bˇehu (aktuáln´ı vlákno, jednotlivé ˇrádky zdrojového kódu, apod), tyto informace mohou pomoci opravit nalezenou chybu. Základn´ı architektura Java PathFinderu je vyobrazena na obr.4.1.

Obr´azek 4.1: Architektura Java PathFinderu [9]

Vstupem JPF je Java byte-code program, který je urˇcen k verifikaci. Na bˇeh JPF jsou pˇrilinkovány r˚uzné moduly, které definuj´ı jakým zp˚usobem bude verifikace prob´ıhat. Po-moc´ı nastaven´ı JPF se urˇc´ı, jaká vyhledávac´ı strategie (search strategy) bude pouˇzita pro prohledáván´ı stavového prostoru, které listenery (search listener) budou s touto stra-tegi´ı pouˇzity (pro z´ıskán´ı poˇzadovaných informac´ı). Dále lze nastavit generován´ı moˇznost´ı (choice generator) nedeterminismu, jedná se o hodnoty vstupn´ıch dat, prokládán´ı vláken atd. Dalˇs´ı nastaven´ı umoˇznuje pˇrilinkovat listener zaloˇzený na sledován´ı jednotlivých krok˚u virtuáln´ıho stroje. JPF tedy systematicky, podle zvolené strategie, prohledává stavový pro-stor vstupn´ıho programu, pokud dojde k detekci chyby. JPF uˇzivateli poskytne zprávu o verifikaci, která obsahuje cestu, která vedla k chybˇe, typ detekovaného problému a dalˇs´ı informace, které byly nastaveny uˇzivatelem.

(25)

JPF umoˇzˇnuje verifikovat programy, které maj´ı v´ıce vláken, nicménˇe neumoˇzˇnuje verifi-kaci soubˇeˇzného bˇehu vláken (na dvou procesorech). JPF pouze simuluje soubˇeˇznost vláken. Zároveˇn neumoˇzˇnuje zverifikovat programy, které obsahuj´ı nativn´ı metody (metody psané v jiném jazyce neˇz Java). JPF neobsahuje podporu vˇsech knihoven Java, pokud program obsahuje urˇcité knihovny, nen´ı ho moˇzné verifikovat [9].

Nicménˇe umoˇzˇnuje vytvoˇren´ı nativn´ıch metod, které jsou v rámci verifikace brány jako atomické ˇcásti kódu a neprovád´ı se nad nimi verifikace. Metoda je vykonána bez prokládán´ı jinými instrukcemi kódu. D´ıky tomuto mechanizmu je moˇzné verifikovat programy obsa-huj´ıc´ı knihovny nebo metody, které nechceme brát v úvahu do verifikace. Pro verifikaci vstupn´ıch dat obsahuje JPF specializované API, pomoc´ı kterého lze urˇcit, jakých hodnot mohou tyto data nabývat. Jinou moˇznost´ı je volba pro náhodný výbˇer hodnot vstupn´ıch dat. Nast´ınˇené vlastnosti JPF budou dále rozepsány. JPF m˚uˇze simulovat nedeterminismus, pro generován´ı nedeterminismu obsahuje JPF dva mechanismy:

• Backtracking znamená, ˇze se JPF m˚uˇze vrátit k vykonanému stavu a nahradit zvo-lenou moˇznost (hodnotu promˇenné), z které vznikl nedeterminismus, jinou moˇznost´ı a t´ım vygenerovat nový stav a následnˇe generovat cestu. Tento zp˚usob se aplikuje na postupné rozgenerován´ı vˇsech moˇzných plánovac´ıch sekvenc´ı (moˇzných hodnot). • State matching je zaloˇzen na mechanismu vyhnut´ı se generován´ı jednoho stavu

systému dvakrát, kaˇzdý nový stav je uloˇzen na heap. Pokud je daný stav uloˇzen, neukládá se jiˇz vygenerovaný stav, ale JPF se vrac´ı k prvn´ımu nerozgenerovanému stavu a zde se pokraˇcuje s verifikac´ı.

4.2 Specifikace

JPF umoˇzˇnuje verifikovat r˚uzné vlastnosti podle zadaných poˇzadavk˚u. V JPF existuj´ı tˇri základn´ı mechanizmy pro nastaven´ı vlastnost´ı: ordinary assertions, gov.nasa.jpf.Property a listenery (gov.nasa.jpf.SearchListner nebo gov.nasa.jpf.VMListener).

Java assertions se zadávaj´ı pˇr´ımo do zdrojového kódu programu a slouˇz´ı k z´ıskán´ı informac´ı závislých pˇr´ımo na datech aplikace. Jedná se o úˇcinné z´ıskán´ı informac´ı a chován´ı systému. Nevýhodou této metody je nutnost zásahu do zdrojového kódu programu. Zároveˇn m˚uˇze doj´ıt k nár˚ustu stavového prostoru, pokud se maj´ı zverifikovat i pˇridané assertions.

Gov.nasa.jpf.Property je mechanismem zapouzdˇruj´ıc´ım kontrolu vlastnost´ı (proper-ties). Verifikace tˇechto vlastnost´ı m˚uˇze být nastavena staticky pomoc´ı search.properties nebo dynamicky pomoc´ı jpf.getSerach().addProperty(). Potom je moˇzné tyto vlast-nosti kontrolovat za bˇehu programu pˇri kaˇzdé zmˇenˇe pomoc´ı search objektu. Základn´ı specifikace, které jsou implicitnˇe v JPF pomoc´ı tohoto mechanizmu kontrolovány jsou následuj´ıc´ı: deadlocks, assertion violation, uncaught exceptions. Kontrola tˇechto specifikac´ı je jiˇz v JPF naiplementována.

Listenery – gov.nasa.jpf.SearchListener a gov.nasa.jpf.VMListener jsou dalˇs´ım mechanismem, který lze vyuˇz´ıt pro ovˇeˇren´ı komplexnˇejˇs´ıch informac´ı. Jedná se o dvˇe tˇr´ıdy, pomoc´ı kterých jsou naimplementovány r˚uzné listnery. Ty slouˇz´ı k z´ıskáván´ı r˚uzných in-formac´ı o bˇehu programu. V JPF je jiˇz ˇrada tˇechto listener˚u naimplementována. Jed-notlivé listenery dávaj´ı napˇr´ıklad následuj´ıc´ı inforamce: SearchMonitor – výpis statistický informac´ı o bˇehu programu (poˇcet vygenerovaných stav˚u, velikost vyuˇzité pamˇeti, atd.),

(26)

HeapTracker – výpis vyuˇzit´ı haldy (heap) na vˇsech cestách verifikace, StateSpaceDot – vytvoˇr´ı graf vygenerovaného stavového prostoru bˇehem verifikace, MethodTracker – výpis vˇsech metod, které byly bˇehem verifikace volány, atd.

Mechanizmus listener˚u umoˇznuje z´ıskávát informace o programu na tˇrech úrovn´ıch. Obecné listenery poskytuj´ı informace o programu z´ıskané pomoc´ı rozhran´ı, nacházej´ı se mimo program. Jedná se o SearchListnery a VMListenery. Druhým typem listener˚u jsou specializované vyhledávac´ı listenery, ty se opˇet nacház´ı mimo program a jsou k nˇemu pouze linkovány. Nicménˇe jsou navrˇzeny pro z´ıskán´ı specifických informac´ı o programu, nebo jsou navrˇzeny ke konkrétn´ımu úˇcelu, napˇr. gov.nasa.jpf.search.heuristic.BFSHeuristic slouˇz´ı pro nastaven´ı prohledáván´ı stavového prostoru pomoc´ı BFS strategie. Tˇret´ım ty-pem listener˚u jsou vnitˇrn´ı listenery, které se nacház´ı v konkrétn´ım bal´ıku uvnitˇr imple-mentace JPF a umoˇznuj´ı z´ıskávat inforamce z daného konkrétn´ıho bal´ıˇcku. Napˇr. bal´ık gov.nasa.jpf.jvm.bytecode obsahuje jednotlivé instrukce byte-codu a tedy listener v tom-to bal´ıku umoˇznuje z´ıskat nebo mˇenit primárn´ı informace o jednotlivých instrukc´ıch byte-codu, které jsou ostatn´ım listener˚um skryty. Nejˇsirˇs´ı vyuˇzit´ı nab´ızej´ı obecné listenery, které umoˇznuj´ı z´ıskat nebo mˇenit informace v programu

”bezpeˇcn´ym“ zp˚usobem.

SearchListenery lze pouˇz´ıt pro monitorován´ı prohledávac´ıho procesu stavovým pro-storem. Umoˇznuj´ı zaznamenávat napˇr´ıklad informace o jednotlivých stavech systému nebo vytváˇret graf stavového prostoru, který obsahuje inforamce o postupu stavovým prostorem i základn´ı informace o jednotlivých stavech.

VMListenery mohou zaznamenávat nebo mˇenit jednotlivé kroky provádˇen´ı programu na úrovni virtuáln´ıho stroje. VMListener zle napˇr´ıklad pouˇz´ıt pro monitorován´ı vykonán´ı byte-code instrukc´ı MONITORENTER a MONITOREXIT, které slouˇz´ı k synchronizaci v programu. Monitorován´ı tˇechto instrukc´ı umoˇznuje odhalit chybˇej´ıc´ı synchronizaci nebo naopak detekovat m´ısto vzniku deadlocku.

Pˇrilinkován´ı listener˚u k bˇehu JPF lze provést dvˇema zp˚usoby. Prvn´ım zp˚usobem je sta-tické nastaven´ı vlastnost´ı JPF pˇred jeho spuˇstˇen´ım. Tento mechanizmus umoˇznuje zvolit jednotlivé listnery, které maj´ı být pˇrilinkovány a také nastavit parametry pˇridávaných lis-tener˚u. Druhou moˇznost´ı je dynamické pˇridán´ı listener˚u do bˇehu JPF, lisntener je pˇridán pˇr´ımo do zdrojového kódu aplikace a vyvolán aˇz za bˇehu.

4.3 Prohled´

av´

an´ı stavov´

eho prostoru

JPF obsahuje r˚uzné nastavitelné vyhledávac´ı strategie (Search strategies) pro prohledáván´ı stavového prostoru verifikovaného systému. Naimplementovány jsou základn´ı vyhledávac´ı strategie jako DF S (Depth First Search – prohledáván´ı do hloubky), BF S (Breadth First Search – prohledáván´ı do ˇs´ırky), A∗, Best-F irst or BeamSearch. Zároveˇn je moˇzné na-stavit r˚uzné parametry u jednotlivých strategi´ı jako hloubku prohledáván´ı, prioritu stav˚u, apod. JPF obsahuje i strategie pro náhodný bˇeh programem napˇr.RandomSearch nebo P athSearch. Vhodným výbˇerem prohledávac´ı strategie a jej´ıho nastaven´ı lze ˇr´ıdit gene-rován´ı stavového prostoru a t´ım doc´ılit zverifikován´ı zadané specifikace systému dˇr´ıve, ne-mus´ı doj´ıt k explozi stavového prostoru.

Redukce stavového prostoru.Java PathFinder obsahuje r˚uzné mechanizmy, které maj´ı za c´ıl omezit explozi stavového prostoru. V kapitole 3, která pojednává o Model checkingu jsou vypsány r˚uzné pˇr´ıstupy jak doc´ılit redukce stavového prostoru. Mechanizmy redukce v JPF jsou zaloˇzeny na uvedených principech.

(27)

• Partial Order Reduction (POR) je metoda, která úˇcinnˇe redukuje poˇcet gene-rovaných stav˚u. Poˇcet plánovaných rozhodován´ı (vˇetven´ı) m˚uˇze být znaˇcnˇe omezen, pokud seskup´ıme vˇsechny instrukce v konkrétn´ım vláknˇe, které nemohou zp˚usobit zmˇenu mimo toto vlákno. Takové instrukce jsou seskupeny do jednoho pˇrechodu, pokud program obsahuje hodnˇe vláken, které mezi sebou nesd´ılej´ı data, m˚uˇze být redukce stavového prostoru znaˇcná. Oproti tomu pokud program obsahuje mnoˇzstv´ı sd´ılených dat nebo provázaných operac´ı, redukce pomoc´ı POR je minimáln´ı. JPF provád´ı POR

”on-the-fly“, pˇri provádˇen´ı se nespoléhá na statickou analýzu, ale vy-hodnocuje atomické sekce za bˇehu, resp. urˇcuje, které instrukce mus´ı být vyhodnoceny jako hraniˇcn´ı daného pˇrechodu do nového stavu. Pokud je POR pˇri spuˇstˇen´ı JPF po-volena, vykonávaj´ı se vˇsechny instrukce v aktuáln´ım vláknˇe do okamˇziku neˇz dalˇs´ı instrukce zp˚usob´ı zmˇenu v plánován´ı (scheduling relavant) nebo se m˚uˇze jednat o in-strukci, která zp˚usobuje nedeterminismus. Z Java byte-code instrukc´ı je pouze asi 10% instrukc´ı, které zp˚usobuj´ı zmˇenu v plánován´ı, na obr. 4.2 jsou tyto instrukce vyobrazeny s jejich závislostmi.

Obrázek 4.2: Instrukce maj´ıc´ı vliv na plánován´ı [9]

• Choice Generatory (CG) jsou dalˇs´ım d˚uleˇzitým mechanizmem pro práci s nede-terminismem. CG slouˇz´ı k vytvoˇren´ı vˇsech hodnot, kterých mohou data v programu nabývat nebo k vytvoˇren´ı vˇsech moˇznost´ı plánován´ı. CG jsou jedn´ım z moˇzných ˇreˇsen´ı jak se vyrovnat s problémem vstupn´ıch dat. Pomoc´ı rozhran´ı gov.nasa.jpf.jvm.Verify lze zadat, jakých hodnot maj´ı urˇcité promˇenné nabývat a takto specifikovanými moˇznostmi hodnot promˇenných se provád´ı verifikace. Pokud jsou vstupn´ı data typu boolean nen´ı problém provést verifikaci nad vˇsemi moˇznostmi hodnot, u typu integer jiˇz nastává problém s vygenerován´ım vˇsechn moˇznost´ı hodnot a u promˇenné typu float je to jiˇz velmi nevhodné.

(28)

K ˇreˇsen´ı tohoto problému slouˇz´ı CG, pomoc´ı kterých m˚uˇzeme zadat jakých hodnot má promˇenná nabývat pˇri verifikaci (explicitn´ı urˇcen´ı

”zaj´ımavých“ hodnoty pro ve-rifikaci). Pomoc´ı CG lze vymezit interval moˇzných hodnot Na obr. 4.3(a) typ bo-olean nabývá vˇsech moˇznost´ı, typ integer nabývá hodnot ze zvoleného intervalu a u typu float i po vymezen´ı intervalu z˚ustává velké mnoˇzstv´ı moˇzných hodnot. Proto je zde dalˇs´ı mechanizmus jak urˇcit interval i krok mezi jednotlivými hodnotami. Pˇresné hodnoty promˇenné se pak definuj´ı aˇz pomoc´ı nastaven´ı parametr˚u pˇri spuˇstˇen´ı JPF (obr. 4.3(b)). Tento mechanizmus lze pouˇz´ıt napˇr´ıklad pokud z hlediska verifi-kace je potˇreba pouze zjistit, zda je promˇenná vˇetˇs´ı nebo menˇs´ı neˇz urˇcitý práh. Podle výsledku se zvol´ı jedna ze dvou moˇznost´ı. Je tedy nadbyteˇcné generovat vˇsechny moˇzné hodnoty promˇenné, pokud je relevantn´ı pouze vztah hodnoty k prahu).

Obrázek 4.3: Instrukce maj´ıc´ı vliv na plánován´ı [9]

• Explicitn´ı urˇcen´ı Atomicity spoˇc´ıvá v proveden´ı urˇcitého kódu programu ato-micky. Ta ˇcást kódu, která má být provedena atomicky je explicitnˇe urˇcena uˇzivatelem pomoc´ıVerify.beginAtomic() a Verify.endAtomic(). Zároveˇn mus´ı uˇzivatel zaruˇcit, ˇze d´ıky této atomicitˇe nedojde k nenalezen´ı chyby v systému.

4.4 Rozˇ

siˇ

ritelnost

Pro vyuˇzit´ı JPF v projektu SHADOWS je podstatná jeho vlastnost rozˇsiˇritelnosti. JPF je open source a je tedy moˇzné doimplementovat jiné vlastn´ı moduly nebo funkce. Pro z´ıskán´ı dalˇs´ıch vlastnost´ı z verifikovaného systému je moˇzné vytváˇret nové listenery, nové pro-hledávac´ı strategie. Ty mohou být modifikac´ı jiˇz naimplementovaných a upraveny pro kon-krétn´ı úˇcel nebo je moˇzné vytváˇret nové strategie spojen´ım v´ıce pˇr´ıstup˚u dohromady.