Formális modellezés és verifikáció

Hasonló dokumentumok
Formális verifikáció Modellezés és modellellenőrzés

Alapszintű formalizmusok

Követelmények formalizálása: Temporális logikák. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Alapszintű formalizmusok

Az UPPAAL egyes modellezési lehetőségeinek összefoglalása. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Követelmények formalizálása: Temporális logikák. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel

Alapszintű formalizmusok

A modellellenőrzés érdekes alkalmazása: Tesztgenerálás modellellenőrzővel

Rendszermodellezés. Modellellenőrzés. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

A modell-ellenőrzés gyakorlata UPPAAL

Követelmények formalizálása: Temporális logikák

A formális módszerek szerepe

Korlátos modellellenőrzés. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Temporális logikák és modell ellenırzés

Modellellenőrzés. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Automatikus tesztgenerálás modell ellenőrző segítségével

Részletes szoftver tervek ellenőrzése

Hatékony technikák modellellenőrzéshez: Korlátos modellellenőrzés. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Gyakorló feladatok: Formális modellek, temporális logikák, modellellenőrzés. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Időzített rendszerek és az UPPAAL II

Modellellenőrzés. dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Szoftver-modellellenőrzés absztrakciós módszerekkel

... S n. A párhuzamos programszerkezet két vagy több folyamatot tartalmaz, melyek egymással közös változó segítségével kommunikálnak.

Hardver és szoftver rendszerek verifikációja Röviden megválaszolható kérdések

A formális módszerek szerepe

Formális módszerek. A formális modellezés és a formális verifikáció alapjai. dr. Bartha Tamás BME Közlekedés- és Járműirányítási Tanszék

Valószínűségi modellellenőrzés Markov döntési folyamatokkal

Modellellenőrzés a vasút automatikai rendszerek fejlesztésében. XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő

Időzített átmeneti rendszerek

Részletes tervek ellenőrzése

Occam 1. Készítette: Szabó Éva

Modell alapú tesztelés mobil környezetben

Szoftverminőségbiztosítás

Zárthelyi mintapéldák. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék

Elérhetőségi analízis Petri hálók dinamikus tulajdonságai

Formális módszerek GM_IN003_1 Program verifikálás, formalizmusok

Osztott rendszer. Osztott rendszer informális definíciója

Modellezés Petri hálókkal. dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék

Intervenciós röntgen berendezés teljesítményszabályozójának automatizált tesztelése

Kiterjesztések sek szemantikája

A fejlesztési szabványok szerepe a szoftverellenőrzésben

Sztochasztikus temporális logikák

Forráskód generálás formális modellek alapján

Időt kezelő modellek és temporális logikák

6. Közös változóval rendelkező párhuzamos program, Közös változó,

Algoritmusok Tervezése. 6. Előadás Algoritmusok 101 Dr. Bécsi Tamás

Hardver és szoftver rendszerek verifikációja Röviden megválaszolható kérdések

BPEL nyelvű üzleti folyamatok modellezése és formális ellenőrzése

A formális módszerek szerepe

HORVÁTH ZSÓFIA 1. Beadandó feladat (HOZSAAI.ELTE) ápr 7. 8-as csoport

Elosztott adatbázis-kezelő formális elemzése

Nagy bonyolultságú rendszerek fejlesztőeszközei

2. gyakorlat: Részletes tervek és forráskód ellenőrzése

BASH script programozás II. Vezérlési szerkezetek

Modellezés UPPAAL-ban

Hardver leíró nyelvek (HDL)

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Java II. I A Java programozási nyelv alapelemei

Szoftverminőségbiztosítás

Formális módszerek GM_IN003_1 Bevezetés

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Modellezési alapismeretek

Automatikus kódgenerálás helyességének ellenőrzése

Hatékony technikák modellellenőrzéshez: Szimbolikus technikák (ROBDD)

BUDAPESTI MÛSZAKI EGYETEM Méréstechnika és Információs Rendszerek Tanszék. SPIN Mérési útmutató. Készítette: Jávorszky Judit

Modell alapú tesztelés: célok és lehetőségek

Formális módszerek. A formális modellezés és a formális verifikáció alapjai. dr. Bartha Tamás BME Közlekedés- és Járműirányítási Tanszék

Monitorok automatikus szintézise elosztott beágyazott rendszerek futásidőbeli verifikációjához

Digitális technika (VIMIAA02) Laboratórium 5

Digitális technika (VIMIAA02) Laboratórium 5

Programozás Minta programterv a 1. házi feladathoz 1.

Digitális technika (VIMIAA02) Laboratórium 4

8. Komponens elvű programfejlesztés. Ágens, akció, cél, kontraktus.

Java programozási nyelv

Futásidőbeli verifikáció

8.3. AZ ASIC TESZTELÉSE

Termelő-fogyaszt. fogyasztó modell

Specifikáció alapú teszttervezési módszerek

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Specifikáció alapú teszttervezési módszerek

Programok értelmezése

Modellezési alapismeretek

Bokor Péter. DECOS Nemzeti Nap október 15. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Dr. Mileff Péter

Laborgyakorlat 3 A modul ellenőrzése szimulációval. Dr. Oniga István

Teljesítmény Mérés. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Teljesítmény Mérés / 20

III. Alapfogalmak és tervezési módszertan SystemC-ben

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

Ütem Lámpafázisok A számláló értéke ütemmerker 1 P 0 M1 2 P 1 M2 3 P S 2 M3 4 Z 3 M4 5 Z 4 M5 6 Z 5 M6 7 Z 6 M7 8 S 7 M8

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

3. gyakorlat Folyamatmodellek, kooperáló viselkedésmodellek Megoldások

Hatékony technikák modellellenőrzéshez: Szimbolikus technikák (ROBDD)

Szekvencia diagram. Szekvencia diagram Dr. Mileff Péter

Dinamikus modell: állapotdiagram, szekvencia diagram

UNIX: folyamatok kommunikációja

Programozási nyelvek a közoktatásban alapfogalmak I. előadás

Átírás:

Formális modellezés és verifikáció Rendszertervezés és -integráció előadás dr. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék BME-MIT

Célkitűzések BME-MIT 2.

Egy mérnöki feladat Többprocesszes alkalmazás (konkurens processzek) Cél: Egy hardver erőforráshoz egyszerre csak egy processz férhessen hozzá (kölcsönös kizárás kell) o Példa: Kommunikációs csatorna használata o Védendő kritikus szakasz a programban o A platform (futtató rendszer) nem ad ehhez támogatást: nincs szemafor, monitor, stb. o Csak megosztott változók (egy művelettel olvashatók vagy írhatók) használhatók Hogyan valósítsuk meg? o Klasszikus megoldások keresése o Saját algoritmus kidolgozása BME-MIT 3. 3

Egy lehetséges algoritmus Kölcsönös kizárás 2 résztvevőre, 3 megosztott változóval (Hyman, 1966) o blocked0: Első résztvevő (P0) be akar lépni o blocked1: Második résztvevő (P1) be akar lépni o turn: Ki következik belépni (0 esetén P0, 1 esetén P1) while (true) { P0 blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } while (true) { P1 blocked1 = true; while (turn!=1) { while (blocked0==true) { skip; } turn=1; } // Critical section blocked1 = false; // Do other things } Helyes-e ez az algoritmus? BME-MIT 4.

Mit jelent a helyesség? Kölcsönös kizárás: o Egyszerre csak az egyik résztvevő lehet a kritikus szakaszban Lehetséges az elvárt viselkedés: o P0 egyáltalán be tud lépni a kritikus szakaszba o P1 egyáltalán be tud lépni a kritikus szakaszba Nincs kiéheztetés: o P0 mindenképpen be fog lépni a kritikus szakaszba o P1 mindenképpen be fog lépni a kritikus szakaszba Holtpontmentesség: o Nem alakul ki kölcsönös várakozás (leállás) BME-MIT 5.

Hogyan ellenőrizhetjük a helyességet? Implementációval majd teszteléssel o Létre tudunk-e hozni minden lehetséges végrehajtást lefedő teszteseteket? (Itt konkurens processzekről van szó!) o A problémás esetek figyeléséhez külön ellenőrző kell o A hiba csak az implementáció után derül ki, drágán javítható Modellezéssel és szimulációval o Tudunk-e szimulálni minden lehetséges végrehajtást? o A problémás esetek detektálása nagy odafigyelést igényel o A hibák viszont olcsóbban javíthatók modell szinten Modellezéssel és az állapottér teljes ellenőrzésével o Szisztematikus algoritmus az állapottér teljes felvételéhez o Automatikus a követelmények teljesülésének figyelése, ha ehhez a helyességi követelményeket formalizáljuk BME-MIT 6.

Ellenőrzések a tervezési fázisban Követelmények elemzése Rendszer specifikálás Formális modellezés: Üzemeltetés, karbantartás Rendszer matematikailag precíz modell validáció készítése Formális verifikáció: Rendszer formalizált követelmény verifikáció ellenőrzése a modellen Architektúra tervezés Rendszer integrálás Modul tervezés Modul verifikáció Modul implementáció BME-MIT 7.

IEC 61508: Functional safety in electrical / electronic / programmable electronic safety-related systems Példa: Szoftver architektúra tervezés Módszerek és intézkedések BME-MIT 8.

Mit szeretnénk elérni? Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 9.

Modellezés: Időzített automaták BME-MIT 10.

Mit szeretnénk elérni? Modellezés időzített automatákkal Magasabb szintű modellekből automatikus transzformációval származtatható Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 11.

Automaták és változók Cél: Állapot alapú viselkedés modellezése Alap formalizmus: Véges állapotú automata (FSM) o Állapotok (más néven vezérlési helyek, névvel hivatkozhatók) o Állapotátmenetek Kiterjesztés: Egész értékű változók használata o Számítások, adatmanipuláció modellezése (egész aritmetikával) o Változók típusa, értéktartománya megadható o Konstansok definiálhatók Állapotátmenetek kiterjesztése: o Őrfeltétel hozzárendelése: A változókon kiértékelhető predikátum, az átmenet bekövetkezéséhez igaz kell legyen o Akció hozzárendelése: Értékadás változóknak BME-MIT 12.

Kiterjesztések óraváltozókkal Cél: Idő függvényében változó viselkedés vizsgálata o Idő telik az állapotokban o Eltelt időtől (nem csak az állapottól) függő viselkedés o Gyakorlati megvalósítás: időzítők (számlálók) Modellezési kiterjesztés: Óraváltozók o Azonos lépésben haladó konkurens órák (időzítők modellje) o Relatív időmérés (pl. time-out): Időzítők resetelése és leolvasása Használat állapotátmenetekben: o Akciók: Óraváltozók nullázása (resetelés), egymástól függetlenül o Őrfeltételek: Óraváltozók és konstansok a feltételekben Használat állapotokban: o Állapot invariánsok: Óraváltozók és konstansok segítségével megadja, meddig állhat fenn az adott állapot BME-MIT 13.

Időzített automata Állapot név clock x; bool activated = false; Őrfeltétel Invariáns Akció BME-MIT 14.

Az invariánsok és őrfeltételek szerepe clock x; bool activated = false; Őrfeltétel Invariáns Az open állapot elhagyásakor a [4, 8] tartományban lehet x értéke 4 8 t BME-MIT 15.

Kiterjesztések elosztott rendszerekhez Cél: Együttműködő automaták hálózatának modellezése o Itt: Különálló automaták átmeneteinek együttes végrehajtása o Együttlépő átmenetek (randevú): szinkron kommunikáció Üzenet küldés és fogadás csak együtt valósulhat meg (küldő vár) Ezzel aszinkron kommunikáció is leírható Kiterjesztés: Szinkronizált akciók o Csatornák definiálása (szinkron csatorna) o Üzenetküldés:! operátor a csatornára Üzenetfogadás:? operátor a csatornára Pl: az a nevű csatorna esetén a! és a? akciók o Csatornatömbök is használhatók Pl. a[id] csatorna az id változóval indexelve a! a? chan a BME-MIT 16.

Példa óraváltozókra és szinkronizálásra Deklarációk: clock t, u; chan press; Kapcsoló: Üzenet fogadás Felhasználó: Üzenet küldés BME-MIT 17.

További lehetőségek Broadcast csatorna o Egy küldő (mindig tud küldeni) o Több fogadó (ha éppen tud, akkor szinkronizál a küldővel) Urgent csatorna: késleltetés korlátozása o Késleltetés nélkül, azonnal végrehajtandó szinkronizáció (de előtte átlapolva azonnali végrehajtás lehet) Urgent állapot: késleltetés korlátozása o Nem telhet idő az adott állapotban (különben hiba) broadcast chan a; a! urgent chan a; a! Nem szerepelhet itt invariáns Nem szerepelhet itt időzítés őrfeltétel U a? a? a? Committed állapot: Atomi végrehajtást ír elő o A kimenő átmenet végrehajtása előtt más automata átmenete nem lehet végrehajtva: bemenő és kimenő átmenet egy atomi művelet C BME-MIT 18.

Az UPPAAL eszköz Fejlesztése (1999-): o Uppsala University, Svédország o Aalborg University, Dánia Web lap (információk, letöltés, példák): http://www.uppaal.org/ Kapcsolódó eszközök: o UPPAAL CoVer: Tesztgenerálás o UPPAAL TRON: On-line tesztelés o UPPAAL PORT: Komponens alapú rendszerek tervezése o Kereskedelmi verzió: http://www.uppaal.com/ BME-MIT 19.

Automata modell BME-MIT 20.

Szimulátor BME-MIT 21.

Követelmények formalizálása: Temporális logikák --> BME-MIT 22.

Mit szeretnénk elérni? Automatikusan ellenőrizhető, precíz követelmények megadása Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 23.

Ellenőrizendő követelmények (példa) Egy példa az ellenőrizendő követelmények jellegére: Egy klímaberendezés állapotai: o Kikapcsolva, bekapcsolva, elromlott, gyengén hűt, erősen hűt, fűt, szellőztet A klíma néhány működési követelménye: o Bekapcsolás után szellőztetést kezd o Erős hűtés csak gyenge hűtés után következhet o Amíg a fűtés be nem fejeződik, addig szellőztetni kell o Ha a klíma elromlott, nem fűthet o... BME-MIT 24.

Állapotokra vonatkozó követelmények Lokális: Egy-egy állapotra vonatkozó o Az adott állapotban eldönthető a teljesítése (pl. az állapotváltozók értékei alapján) o Példa: A kezdeti állapotban legyen szellőztetés Elérhetőségi: Több állapot bekövetkezési sorrendjére vonatkozó követelmények o Az állapottér vizsgálatával dönthető el a teljesítése o Példa: A fűtési fázis befejezése után szellőztetni kell o Folyamatosan működő rendszerekre is alkalmas o A tipikus követelmények jellege: A rendszer biztonsága A rendszer élő jellege BME-MIT 25.

A követelmények típusai Biztonsági jellegű követelmények Veszélyes, nemkívánatos helyzetek elkerülését írják elő: o Minden állapotban kisebb a nyomás a kritikusnál. o A présgép csak becsukott ajtó mellett üzemel. o A processzek között mindig teljesül a kölcsönös kizárás. Formálisan: Invariáns tulajdonság o Minden elérhető állapotban igaz, hogy Élő jellegű követelmények Kívánatos helyzetek elérését írják elő o Az indítás után a présgép kiadja az elkészült terméket. o A zavarás után a folyamat visszakerül stabil állapotba. o Az elküldött üzenet feldolgozása megtörténik a fogadónál. Formálisan: Állapotok elérését fogalmazzák meg: o Elérhető olyan állapot, hogy BME-MIT 26.

Követelmények leíró nyelve Elérhetőség: Több állapot bekövetkezési sorrendjére vonatkozó követelmények o Állapotok egymásutánisága mint logikai idő vehető figyelembe Jelen időpillanat: Aktuális állapot Következő időpillanat: Rákövetkező állapot(ok) s.í.t. o Temporális (logikai időbeli, sorrendi) operátorok használhatók a követelmények kifejezésére Temporális operátorok: mindig, valamikor, mielőtt, addig, amíg, azelőtt, hogy, Temporális logikák: o Formális nyelv arra, hogy kijelentések igazságának logikai időbeli változását vizsgálhassuk BME-MIT 27.

Temporális logikák Lineáris: Egymás utáni állapotok egy sorozatot alkotnak: minden állapotnak egy rákövetkezője van logikai idő mint idővonal {Zöld} {Sárga} {Piros} s1 s 2 s 3 {Piros, Sárga} Elágazó: {Zöld} s1 Egymás utáni lehetséges {Villogó} állapotok egy fa struktúrában: s5 minden állapotnak {Piros} s3 több rákövetkezője lehet logikai idő elágazó idővonalak mentén s4 {Sárga} s5 s2 {Villogó} {Piros} s3 BME-MIT 28.

A rendszer működése mint számítási fa {Zöld} {Sárga} {Piros} {Piros, Sárga} s1 s 2 s 3 s4 {Villogó} s5 s5 {Villogó} Automata címkézett állapotokkal {Sárga} s2 {Piros} s3 {Villogó} s5 {Piros,Sárga} s4 {Piros} s3 Számítási fa: Lehetséges elágazások {Zöld} s1 s5 {Piros} s3 {Villogó} s5 {Villogó} {Piros,Sárga} s4 BME-MIT 29.

Az utak és állapotok leszámolása Adott állapotból (kezdőállapotból) induló utakat megadó operátorok o A: minden útvonalra o E: legalább egy útvonalra ( for All ) ( Exists ) Adott úton az egymás után bejárt állapotokat megadó operátorok o G: minden állapotra o F: egy jövőbeli állapotra ( Globally) ( Future ) Együtt kell használni ezeket o Utakat mindenképpen meg kell adni az állapotokhoz o AG, AF, EG, EF összetett operátorok BME-MIT 30.

Temporális operátorok (UPPAAL jelölés) Operátor Informális jelentés UPPAAL jelölés AG AF EG EF Minden útvonalon minden állapotra Minden útvonalon a jövőben (előbb-utóbb) Egy létező útvonalon minden állapotra Egy létező útvonalon a jövőben (előbb-utóbb) A[] A<> E[] E<> AG( => AF ) -t követően mindig --> Sehol sincs holtpont A[] not deadlock és Boole-logikai kifejezések órákon, változókon és állapotokon BME-MIT 31.

Minden útvonalra vonatkozó operátorok AG AF AG : Minden útvonalon minden állapotra igaz AF : Minden útvonalon a jövőben előbb-utóbb elérünk olyan állapotba, ahol igaz BME-MIT 32.

Egy-egy útvonalra vonatkozó operátorok EG EF EG : Létezik egy útvonal, ahol minden állapotra igaz Van-e kapcsolat AG és EF között? Van-e kapcsolat AF és EG között? EF : Létezik egy útvonal, ahol a jövőben előbbutóbb elérünk olyan állapotba, ahol igaz BME-MIT 33.

Feltételes elérhetőség --> AG( => AF ) --> Minden útvonalra és ezeken minden állapotra igaz, hogy bekövetkezése esetén előbb-utóbb mindig elérünk olyan állapotba, ahol teljesül Időzítéssel együtt: --> ( and x <= t) ahol x egy óraváltozó, amit akkor reseteltünk, amikor igaz lett BME-MIT 34.

Néhány példa követelmények formalizálására Adott egy klímaberendezés, aminek a következő üzemmódokat kell biztosítania: {Kikapcsolva, Bekapcsolva, Elromlott, GyengénHűt, ErősenHűt, Fűt, Szellőztet} Ezekre a tulajdonságokra (állapot címkékre) hivatkozhatunk a követelmények formalizálása során Egy állapotban több tulajdonság is fennállhat A követelményeket a kezdőállapotra fogalmazzuk meg A követelmény formalizáláshoz a modellt még nem feltétlenül ismerjük BME-MIT 35.

Néhány példa követelmények formalizálására A klímaberendezés üzemmódjai: {Kikapcsolva, Bekapcsolva, Elromlott, GyengénHűt, ErősenHűt, Fűt, Szellőztet} Példák formalizált követelményekre: A bekapcsolt klíma előbb-utóbb mindig szellőztet: AF (Bekapcsolva Szellőztet) Ha a klíma elromlott, nem fűthet (nem lehet ilyen hibamód): AG ( (Elromlott Fűt)) Fűtés után mindig szellőztetni kell: AG(Fűt => AF (Szellőztet)) vagy Fűt --> Szellőztet A gyenge hűtést lehetőség van bekapcsolni: EF (GyengénHűt) Lehetséges olyan működtetés, hogy soha sincs erős hűtés: EG ( ErősenHűt) BME-MIT 36.

A modellellenőrzés működése Időzített automata Temporális logika Rendszer modellje Követelmény megadása i Automatikus modellellenőrző n OK Ellenpélda BME-MIT 37.

Az UPPAAL modellellenőrző Követelmények halmaza szerkeszthető Modell ellenőrzés egyenként is indítható Keresés az állapottérben beállítható: o Mélységi vagy szélességi Állapottárolás különféle opciókkal: o Redukció o Alul- illetve felülbecslés Ellenpélda generálható invariánsokhoz: o Legrövidebb, leggyorsabb, vagy akármilyen o Betölthető a szimulátorba (végigjátszható) BME-MIT 38.

Az UPPAAL modellellenőrző ablaka BME-MIT 39.

Ellenpélda a szimulátorban BME-MIT 40.

Mintapélda BME-MIT 41.

Mintapélda: Kölcsönös kizárás 2 résztvevőre, 3 megosztott változóval (H. Hyman, 1966) o blocked0: Első résztvevő (P0) be akar lépni o blocked1: Második résztvevő (P1) be akar lépni o turn: Ki következik belépni (0 esetén P0, 1 esetén P1) while (true) { P0 blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } while (true) { P1 blocked1 = true; while (turn!=1) { while (blocked0==true) { skip; } turn=1; } // Critical section blocked1 = false; // Do other things } Helyes-e ez az algoritmus? BME-MIT 42.

A modell UPPAAL-ban (első változat) Deklarációk: bool blocked0; bool blocked1; int[0,1] turn=0; system P0, P1; A P0 automata: Kihasznált modellezési lehetőségek: Közös változók rendszerszintű deklarálása Korlátozott értékkészletű változók while (true) { blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } P0 BME-MIT 43.

A modell UPPAAL-ban (második változat) Deklarációk: bool blocked[2]; int[0,1] turn; P0 = P(0); P1 = P(1); system P0,P1; A P automata (template) pid paraméterrel: Kihasznált modellezési lehetőségek: Közös változók rendszerszintű deklarálása Korlátozott értékkészletű változók Azonos viselkedésű résztvevők azonos automata template alapján Példányosítás paraméterezéssel Változó tömbök (résztvevőkhöz) while (true) { blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } P0 BME-MIT 44.

Ellenőrizendő követelmények Kölcsönös kizárás: o Egyszerre csak az egyik résztvevő lehet a kritikus szakaszban Lehetséges az elvárt viselkedés: o P0 egyáltalán be tud lépni a kritikus szakaszba o P1 egyáltalán be tud lépni a kritikus szakaszba Nincs kiéheztetés: o P0 mindenképpen be fog lépni a kritikus szakaszba o P1 mindenképpen be fog lépni a kritikus szakaszba Holtpontmentesség: o Nem alakul ki kölcsönös várakozás (leállás) BME-MIT 45.

UPPAAL: A követelmények formalizálása Kölcsönös kizárás: o Egyszerre csak az egyik résztvevő lehet a kritikus szakaszban: A[] not (P0.cs and P1.cs) Holtpontmentesség: o Nem alakul ki kölcsönös várakozás (leállás): A[] not deadlock Lehetséges az elvárt viselkedés: o P0 egyáltalán beléphet a kritikus szakaszba: E<>(P0.cs) o P1 egyáltalán beléphet a kritikus szakaszba: E<>(P1.cs) Nincs kiéheztetés: o P0 mindenképpen be fog lépni a kritikus szakaszba: A<>(P0.cs) o P1 mindenképpen be fog lépni a kritikus szakaszba: A<>(P1.cs) BME-MIT 46.

UPPAAL: A modellellenőrzés eredménye Nincs holtpont Az élő jellegű követelmények teljesülnek o Mindkét processz be tud lépni a kritikus szakaszba (lehetőség) A kölcsönös kizárás nem teljesül! o Ellenpélda: Egy átlapolt végrehajtás, a szimulátorban követhető Kiéheztetés elkerülése (szükségszerű belépés) nem garantálható o Triviális ellenpélda: végtelen sok ideig vár egy állapotban o Ennek elkerülése: pl. urgent állapot (ha ez érvényes viselkedés), vagy időfüggő feltételek és állapot invariánsok o Itt: ezek után is van olyan (ciklikus) viselkedés, ahol az egyik processz kiéhezteti a másikat BME-MIT 47.

A kölcsönös kizárás hibájának javítása Hyman: Peterson algoritmusa P0 résztvevőre (P1 értelemszerű): Peterson: while (true) { blocked0 = true; while (turn!=0) { while (blocked1==true) { skip; } turn=0; } // Critical section blocked0 = false; // Do other things } while (true) { blocked0 = true; turn=1; while (blocked1==true && turn!=0) { skip; } } // Critical section blocked0 = false; // Do other things BME-MIT 48.

A modellellenőrzés tulajdonságai BME-MIT 49.

A modellellenőrzés használata Követelmények elemzése Követelmények Üzemeltetés, karbantartás Rendszer validáció Rendszer specifikálás Modellek Rendszer verifikáció Architektúra tervezés Rendszer integrálás Modul tervezés Modul implementáció Modul verifikáció Új alkalmazások: Modellellenőrzés a forráskód alapján (modell visszafejtés, absztrakció) BME-MIT 50.

A modellellenőrzés tulajdonságai Kedvező tulajdonságok: o Garantált eredményt ad: Teljes állapottér bejárás o Lehetséges nagy modell állapotteret is kezelni (kompakt tárolással) Akár 10 20, de példa van 10 100 méretű állapottér ellenőrzésére is o Teljesen automatikus eszköz, nem szükséges tervezői intuíció és erős matematikai háttérismeret o Ellenpéldát generál, ami segít a hibák javításában Problémák: o Skálázhatóság nem biztosított (explicit állapottér bejárás) o Elsősorban vezérlés-orientált alkalmazásokra hatékony Komplex adatstruktúrák hatalmas állapotteret jelentenek o Nehéz az eredményeket általánosítani Ha egy protokoll helyes 2 résztvevő esetén, akkor helyes-e n esetén? o A követelmények formalizálása komplikált Nyelvjárások alakultak ki különböző alkalmazási területeken BME-MIT 51.

Továbblépés Az ellenőrzött modellek felhasználása Forráskód generálás Monitor szintézis futásidőbeli verifikációhoz Dokumentáció készítés BME-MIT 52.