Modellellenőrző szoftverek

Átírás

1 Modellellenőrző szoftverek Dr. Németh L. Zoltán Első előadás SZTE, Informatikai Tanszékcsoport 2008/2009 I. félév Modell 1 1

2 Az előadás vázlata A modellellenőrzés jelentőssége, alapjai A SPIN és használata A PROMELA nyelv szintaktikája, szemantikája (példák) Helyességi kritériumok megfogalmazása (LTL logika) Komplex konkurens modellezési példák Időzített rendszerek és időzített automaták Az UPPAAL modellellenőrző Példák időzített rendszerek ellenőrzése Modell 1 2

3 Motivációk ICT(Information and Communication Thechnology) rendszerek mindennapjainkban renszerek vezérlése (mindenhol) internet: e-bankok, e-vásársárlás, e-ügyintézés, e- beágyazott rendszerek (embedded systems): intelligens kártyák, mobilok, autók, szórakoztató elektronika, orvosi műszerek, stb. Egyre nő az igény az ICT rendszerek megbízhatóságára (A,,Ha a Microsoft autókat gyártana vicc nagyon komoly! ) Ugyanakkor a rendszerek komplexitása, elképesztően gyorsan nő (komponensek száma, funkcionalitása, interaktivitás, környezettől való függés, nem determinisztikusság, időfüggés, elosztottság, stb. ) Ma már intuitív eszközökkel komplex rendszerek nem tervezhetők/készíthetők => a formális (matemetikai( matemetikai) ) módszerek m térht rhódítása mind a tervezésben mind az ellenőrz rzésben Modell 1 3

4 Sajnos Arine 5 rakéta (1996) indítás után 36 másodpercel felrobbant egy 64 bites lebegőpontos sebesség-adat 16 bites egésszé való hibás konvertálása miatt A Terrac-25 radioterápiás készülék balesetei ( ) 6 ember halt meg túladagolás miatt A varsói légiszerencsétlenség (1993) Mars Pathfinder (1997) A megbízható működés elengedhetetlen biztonsági és anyagi okokból Modell 1 4

5 Ellellenőrzés Egy (szoftver) rendszer helyes, ha megfelel a vele szemben tervezéskor támasztott elvárásoknak. Ebben mindenki egyetért, de hogyan lehet ezt ellenőrizni? Szoftver ellenőrzési techikák: Tesztelés Peer reviewing (társak általi ellenőrzés) Formális módszerek Hardver ellenőrzési techikák: - Szerkezeti elemzés (Structural Analysis) - Emuláció - Szimuláció Modell 1 5

6 Tesztelés Minden szoftvertervezési projekt része A költségek 30-50%-át fordítják rá!!! Tesztgenerálás és futtatás (félig) automatikusan Az összehasonlítást általában ember végzi A tesztelés általában nem képes ezt miden esetet kimerítően bizonyítani. Csak általános, tipikus szituációkat vizsgál. Nehéz megmondani, hogy mikor érdemes abbahagyni,,a A program tesztelés s csak a hibák k kimutatására használhat lható,, de sohasem azok hiány nyának nak igazolására ra. (Dijkstra) Modell 1 6

7 Peer Reviewing Szoftverfejlesztők (ideális esetben nem a készítők!) elemzik a kódot, annak végrehajtása nélkül Annak ellenére, hogy manuális módszer meglehetősen hatékony: A hibák 31-93%-át (átlagban 60%-át) lehet így felefedezni Szoftverfejlesztési projektek közel 80%-ban alkalmazzák De a nehezen észrevehető hibák sokszor továbbra is megmaradnak Modell 1 7

8 Konkurens rendszerek este Egyidejű (konkurens) rendszerekre tervezése és ellenőrzése különösen nehéz!!! az folyamatok végrehajtási sorrendje nemdeterminisztikus legalább is nem megfigyelhető / kontrollálható Pl. a folyamatok ütemezés egyidejűleg egy nagy hálózat különböző egymástól távoli processzorain törtéhet. tesztelésnél a javításhoz a hibát reprodukálni kell tudni! De pontosan ugyanazt a futást, ami a nemdeterminisztikus környezettől is függhet hogyan ismételjük meg? Modell 1 8

9 Konkurencia mindenütt Áruházban a vevők (áruk, pénztárak), a bejáratnál: 2 udvarias vagy 2 törtető ember találkozása Telefonközpont mi van, ha ketten egyszerre hívják egymást? Közlekedés (elsőbbségadás) jobbkézszabály, körforgalom, táblák, lámpák Osztott rendszerek, többfelhasználós rendszerek, adtbázisok stb Modell 1 9

10 Formális módszerek ellenőrzésre Formális módszer,,alkalmazott matematika ICT rendszerek modellezésére és elemzésére A rendszer helyességét matematikai szigorral bizonyítják A fejlesztés korai fázisában alkalmazhatók, már a tervezéskor Modell alalpú módszerek modell alapú szimuláció modellellenőrzés modell alapú tesztelés Deduktív módszerek tétel bizonyítók (theorem proovers) bizonyítás ellenőrzők (proof checkers) Modell 1 10

11 Modellellenőrzés Adott a rendszer (program) egy véges állapotú modelljét készítjük el: (M) Egy logikai tulajdonság (p) írja le a specifikációt (a kívánt viselkedést) A modellellenőrzés egy olyan automatikus módszer, mely szisztematikusan ellenőrzi, hogy e tulajdonság fennáll-e a rendszerben. Ha a tulajdonság nem teljesül, akkor a modellellenőrző egy ellenpéldát ad, ami alapján a hiba javítható Modell 1 11

12 A modellelenőrzés végeletei verifikáció: bizonyítsuk be, hogy a tervezés alatt álló rendszer M modellje teljesíti a követelményekben megfogalmazott p tulajdonságo(ka)t hibakutatás (debugging): keressünk hibákat az M rendszermodellben Persze a p tulajdonságnak helyesen kell leírni a specifikációt. A specifikációtól elvárás, hogy - zárt/teljes (minden esetre kiterjedő) és - ellentmondásmentes legyen Modell 1 12

13 Verifikácó - validáció Maga a modellellenőrzés, a verifikáció csak akkor ér valamit, ha 1. a modell helyesen írja le a rendszert és 2. a specifikáció helyesen írja le a követelményeket Ezért ezt is ellenőrizni kell, ezt szokták validációnak hívni. Másként fogalmazva: validáció: Jó rendszert építünk-e? (tényleg erre van-e szükség?) verifikáció: Jól építjük-e a rendszert? (a modell teljesíti-e a már validált specifikációt) Modell 1 13

14 Alkalmazási területek Biztonságkritikus rendszerek: orvosi berendezések repülésirányítás katonaság Missziókritikus rendszerek: űrkutatás Adatvédelmi rendszerek: bank rendszerek orvosi nyilvátartás De sokszor ipari alkalmazásoknál is kifizetődő - processor gyártás (Pl. Intel Pentium FDIV Bug) - szórakozatató elektronika - autóelektronika stb Modell 1 14

15 Modellellenőrzés a rendszerfejlesztésben Modell 1 15

16 Klasszikus modellellenőrzés Modell 1 16

17 Modern modellellenőrzés Középpontban: absztrakció (szándékos információvesztés) az állapottérrobbanást elkerülendő Ebben a kurzusban: csak a klasszikus megközelítés lesz De pl. a SPIN támogatja a C programokból automatikus modellextrahálást is Modell 1 17

18 A klasszikus modellellenőrzés folyamata I. Modellezési fázis (modeling phase) II. a vizsgált rendszer modelljének megalkotása modelleíró + modellellenőrző szoftver segítségével a rendszer vizsgálata/javítása néhány szimulációval az ellenőrizendő tulajdonságok megadása valamilyen specifikáció leíró nyelvben Futtatási fázis (running phase) a modellellenőrző futattása sorra a tulajdonságok ellenőrzésére Modell 1 18

19 A klasszikus modellellenőrzés folyamata II. III. Elemzési fázis (analysis phase) a tulajdonság teljesül? -> ellenőrizzük a következőt (ha még van) a tulajdonság nem teljesül? -> 1. analizáljuk a kapott ellenpéldát szimulációval 2. tervezési/modellezési hiba -> módosítsuk a modellt VAGY a kért tulajdonságban van a hiba -> módosítsuk a specifikációt 3. ismételjük meg az ellenőrzést (azaz vissza II-re) elfogyott a memória? próbáljuk ki a modellellenőrző más beállításait (a modell szimmetria tulajdonságainak kihasználása, szimbólikus technikák) alkalmazzunk erősebb absztrakciót a modellezésben, esetleg csak külön ehhez a tulajdonsághoz elégedjünk meg sok véletlenül választott és nem az összes lehetséges állapot vizsgálatával Modell 1 19

20 A modellellenőrzés előnyei általános verifikációs technika (hw, sw, beágyazott) paricális verifikáció támogatása, azaz a specifikációnak nem kell teljesnek lennie a hibákat valószínűségüktől függetlenül deríti fel diagnosztikus információt (ellenpédát) is ad az ellenőrzés automatikus, gombnyomásra megy gyorsan terjed ipari alkalmazásokban is könnyen integrálható a meglevő rendszerfejlesztési ciklusba szilárd matematikai alapokra épül (gráf algoritmusok, adatszerkezetek, logika) Modell 1 20

21 A modellellenőrzés hátrányai elsősorban vezérlés-központú rendszerkebn alkalmazható, nem adat-központúakban eldönthetőségi kérdésektől függhet (pl. végtelen állapottér, absztakt adattípusok esetén) csak a renszer modelljét ellenőrzi, nem deríti fel a gyártási (hw) és kódolási (sw) hibákat, (tesztelés is kell!). csak a megfogalmazott tulajdonságokat ellenőrzi, melyek nem feltétlenül teljesek (azaz minden esetre kiterjedőek) az állapottér robbanás komoly memória korlátokat ad a helyes absztrakció megtalálása szakértelmet igényel maga a modellellenőrző szoftver is hibás lehet az ellenőrzés nem általánosítható (tetszőleges paraméterekre és komponens számra) Modell 1 21

22 Az egyik szoftver a SPIN. Miért pont a SPIN? modern modellellenőrző eszköz (egyidejű) szoftver fejlesztésre specializált új elméleti eredmények hatékony implementációjára épül ingyenes jól dokumentált folyamatosan fejlesztett több mint 2000 felhasználó, számuk gyorsan bővül könnyen kezelhető grafikus interfész: XSPIN vagy JSPIN elismert: ACM Software System Award Modell 1 22

23 Modell 1 23

24 Az Xspin dióhéjban Az Xspin szolgáltatásai: Promela modellek szerkesztése (+ szintaxisellenőrzés) szimulációja véletlen (random) interaktív irányított (guided) verifikációja kimerítő (exhaustive) bitstate hashing mód (nem garantál 100%-os bizonyítást) További szolgáltatások bármely processz automatájának felrajzolása LTL formula szerkesztő Súgó(verifikációs és szimulációs támpontok) Modell 1 24

25 SPIN - Bevezetés SPIN (= Simple Promela Interpreter) konkurens rendszerek, különösen kommunikációs protokollok logikai konzisztenciáját ellenőrző eszköz modellezési nyelve: Promela Promela (= Protocol/Process Meta Language) konkurens processzek dinamikus létrehozása kommunikáció csatornákon keresztül: szinkron (azaz randevú), vagy aszinkron (azaz pufferelt). szintaxisában a C programozási nyelvre hasonlít specifikációs nyelv véges állapotú rendszerek modellezésére Modell 1 25

26 Egy példa A Pathfinder 1997, Július 4-én landolt a Marson Egy kis terepjárót bocsátott útjára Elképesztő fizikai és mechanikai problémákat kellett leküzdeni A vezérlőprogram hibája miatt néha előre nem látható pillanatokban megszakadt a kapcsolat a Földdel Modell 1 26

27 A hibás programrész Két egyidőben futó (konkurens) folyamat: A: a gyűjtött adatok memóriába való továbbítását végzi B: a memóriában lévő adatokat a Földre küldi Két egyszerű szabály: Kölcsönös kizárás: a memóriához egyszerre csak az egyik folyamat férhet hozzá megvalósítása egy mutex lock (lakat) változó segítségével Prioritási szabály: a B folyamatnak mindig elsőbbsége van az A folyamattal szemben, azaz A csak akkor futhat, ha B munka nélküli (idle) állapotban van Modell 1 27

28 A folyamatok működése unlock tétlen fut lock vár Modell 1 28

29 A SPIN Model mtype = { free, busy, idle, waiting, running }; mtype h_state = idle; mtype l_state = idle; mtype mutex = free; active proctype high() /* can run at any time */ { end: do :: h_state = waiting; atomic { mutex == free -> mutex = busy }; h_state = running; /* critical section - consume data */ atomic { h_state = idle; mutex = free } od } Modell 1 29

30 A SPIN Model II. active proctype low() provided (h_state == idle) /* scheduling rule */ { end: do :: l_state = waiting; atomic { mutex == free -> mutex = busy}; l_state = running; } /* critical section - produce data */ atomic { l_state = idle; mutex = free } od Modell 1 30

31 Ellenőzése: $ spin a pathfinder $ gcc o pan pan.c $./pan hint: this search is more efficient if pan.c is compiled -DSAFETY pan: invalid end state (at depth 4) pan: wrote pathfinder.trail (Spin Version February 2004) Warning: Search not completed + Partial Order Reduction Modell 1 31

32 Full statespace search for: never claim - (none specified) assertion violations + acceptance cycles - (not selected) invalid end states + State-vector 20 byte, depth reached 4, errors: 1 5 states, stored 1 states, matched 6 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) (max size 2^18 states) Modell 1 32

33 A hiba felderítése: $ spin t p pathfinder 1: proc 1 (low) line 40 "pathfinder" (state 1) [l_state = waiting] 2: proc 1 (low) line 41 "pathfinder" (state 2) [((mutex==free))] 2: proc 1 (low) line 41 "pathfinder" (state 3) [mutex = busy] 3: proc 1 (low) line 42 "pathfinder" (state 5) [l_state = running] 4: proc 0 (high) line 27 "pathfinder" (state 1) [h_state = waiting] 5: proc 0 (high) line 28 "pathfinder" (state 2) [((mutex==free))] transition failed spin: trail ends after 5 steps #processes: 2 h_state = waiting l_state = running mutex = busy 5: proc 1 (low) line 46 "pathfinder" (state 8) 5: proc 0 (high) line 28 "pathfinder" (state 2) 2 processes created Modell 1 33

34 A hiba egy lehetséges javítása active proctype low() provided (h_state == idle) { end: do :: l_state = waiting; (h_state == idle ) atomic { mutex == free -> mutex = busy}; l_state = running; /* critical section - produce data */ atomic { l_state = idle; mutex = free } od} Őrfeltétel, csak akkor lépheti át a folyamat, ha igaz Modell 1 34