Kritinių sistemų kūrimas

1. Kritinių sistemų kūrimas

2. Tikslai • Paaiškinti kaip klaidų toleravimas ir klaidų vengimas prisideda prie pasikliautinų sistemų kūrimo. • Aprašyti pasikliautinų programų kūrimo proceso charakteristikas. • Apibūdinti programavimo metodus klaidoms vengti. • Aprašyti klaidų toleravimo mechanizmus ir naudojimo įvairovė bei pertekliškumą.

3. Įžanga • Kritinių sistemų kūrimas Įžanga (Tikslai, temos, pasikliautinumas, įvairovė ir pertekliškumas, programos be klaidų, jų kūrimas, klaidų ištaisymo kaštai)

4. Temos • Pasikliautinas procesas • Pasikliautinas programavimas • Klaidų toleravimas • Klaidų toleravimo architektūros

5. Programinės įrangos pasikliautinumas • Apskritai PĮ vartotojai tikisi, kad visa PĮ būtų patikima. Kad ir kaip bebūtų, nekritines taikomąsias programas jie gali būti pasiruošę priimti ir su kai kuriais trūkumais • Tačiau kai kurioms taikomosioms programoms keliami labai aukšti patikimumo reikalavimai, ir kad programos juos išpildytų, privalo būti naudojamos specialios programavimo technikos

6. Kaip pasiekti reikiamą pasikliautinumą • Defektų vengimas • PĮ kuriama taip, kad būtų išvengta žmogaus klaidų ir taip būtų sumažintas sistemos defektų kiekis • Kūrimo procesas organizuojamas taip, kad PĮ defektai būtų aptikti ir ištaisyti iki jos pristatymo vartotojui • Defektų toleravimas • PĮ projektuojama taip, kad defektai pristatytoje PĮ nesukeltų sistemoje klaidų

7. Programos be klaidų • Dabartiniai metodai gali užtikrinti gauti santykinai mažas sistemas be klaidų. • Programos be klaidų suprantamos kaip programos programos , kurios atitinka specifikaciją. Bet gali būti specifikacijos klaidų. • Programos be klaidų daug kainuoja tai gali apsimokėti tik išskirtinėse situacijose. Dažnai pigiau priimti programos klaidas ir taisyti pasekmes negu skirti pakankamai resursų programoms be klaidų.

8. Programinės įrangos be defektų kūrimas • Reikalinga tiksli (pageidautina formali) specifikacija • Reikalauja organizacinių priemonių kokybei pasiekti • Informacijos slėpimas ir inkapsuliacija yra būtini dalykai PĮ projektavime • Turėtų būti naudojama programavimo kalba su griežta kintamųjų tipų kontrole (strict typing) ir klaidų tikrinimu kodo rašymo metu (compile-time checking) • Turėtų būti išvengta klaidas sąlygojančių struktūrų • Patikimas ir pakartojamas kūrimo procesas

9. Programų be klaidų kūrimo požymiai • Pasikliautinas kūrimo procesas • Kokybės valdymas • Formalios specifikacijos • Statinis tikrinimas • Griežti kintamųjų tipai • Saugus programavimas • Informacijos apsauga

10. Mažai Labai mažai Daug Neišaiškintų klaidų kiekis Klaidų ištaisymo kaštai Vienos klaidos pašalinimo kaštai

11. Temos • Pasikliautinas procesas (kūrimo procesas, charakteristikos, atestavimo veiklos) • Pasikliautinas programavimas • Klaidų toleravimas • Klaidų toleravimo architektūros

12. Patikimas programinės įrangos kūrimo procesas • Tam, kad užtikrinti minimalų PĮ defektų skaičių, svarbu turėti gerai apibrėžtą, pakartojamą PĮ kūrimo procesą • Gerai apibrėžtas pakartojamas procesas yra toks, kuris nepriklauso vien tik nuo individualių sugebėjimų, bet gali būti įvykdytas skirtingų žmonių • Aišku, kad defektų sumažinimo procesui labai svarbus turėtų būti tikrinimas ir atestavimas

13. Pasikliautino proceso charakteristikos

14. Temos • Pasikliautinas procesas • Pasikliautinas programavimas (informacijos saugojimas, saugus programavimas, klaidas sąlygojančios struktūros, išimčių apdorojimas) • Klaidų toleravimas • Klaidų toleravimo architektūros

15. Pasikliautinas programavimas • Naudoti programavimo konstrukcijas ir metodus kurie prisideda prie klaidų vengimo ir toleravimo. • Projekto paprastumas; • Apsaugoti informaciją nuo nesankcionuoto priėjimo; • Minimizuoti nesaugių programavimo konstrukcijų naudojimą.

16. Informacijos saugojimas • Informacija neapsaugojama tik tose programos dalyse, kur reikia ją pasiekti. Tam reikia naudoti objektus arba abstrakčius duomenų tipus, kurie palaiko būvį ir pagal jį atlieka operacijas. • Taip išvengiama klaidų dėl trijų priežasčių: • Sumažinama tikimybė atsitiktinio informacijos pažeidimo; • Informacija apsupama “ugniasienių, todėl mažiau tikėtina , kad problemos persikels į kitas programos dalis; • Kadangi informacija lokalizuota, mažiau bus padaroma klaidų ir recenzentai tikriausiai suras klaidas.

17. Saugus programavimas • Klaidos programoje yra programuotojų suklydimų pasekmė. • Dažnai klaidos įvyksta, kai žmonės pameta susietumą tarp programos kintamųjų. • Kai kurios programavimo konstrukcijos turi polinkį klaidoms, tai jų vengimas sumažina klaidų kiekį. • Struktūrinis programavimas

18. Klaidas sąlygojančios (error-prone) struktūros • Slankaus taško skaičiai • Pagal savo prigimtį netikslūs. Netikslumas gali sąlygoti neteisingus palyginimus • Rodyklės (Pointers) • Rodyklės, nukreiptos į klaidingas atminties sritis, gali išgadinti duomenis. Pseudonimų naudojimas vietoj tikrų rodyklių vardų (aliasing) gali padaryti programas sunkiai suprantamas ir sunkiai pakeičiamas • Dinaminės atminties paskirstymas • Paskirstymas programos vykdymo metu gali iššaukti atminties perpildymą • Lygiagretumas • Gali pasireikšti subtiliomis veiksmų sinchronizavimo klaidomis (timing errors) dėl nenumatytos sąveikos tarp lygiagrečių procesų

19. Klaidas sąlygojančios (error-prone) struktūros • Rekursija • Klaidos rekursijoje gali iššaukti atminties perpildymą • Pertrauktys • Pertrauktys gali sukelti kritinės operacijos pabaigą ir padaryti programą sunkiai suprantamą. Jos gali būti palyginamos su ‘goto’ sakiniais • Paveldimumas • Kodas nėra lokalizuotas. Tai gali pasireikšti netikėtu elgesiu, kai padaromi pakeitimai, ir suprantamumo problemomis • Šių struktūrų neturėtų būti vengiama, bet jas naudoti reikėtų labai atidžiai

20. Išimčių (exception) apdorojimo operatoriai • Programos išimtis yra klaida arba kažkokie nenumatyti įvykiai, tokie kaip blogas energijos tiekimas • Išimties apdorojimo konstrukcijos leidžia apdoroti tokius įvykius be nuolatinio būsenos tikrinimo, kuris yra reikalingas, kad būtų aptiktos išimtys • Normalių kontrolės konstrukcijų naudojimas, norint aptikti išimtis eilėje kreipinių į įterptinę procedūrą (nested procedure), reikalauja įdėti į programą daug papildomų operatorių ir padidina laiko sąnaudas

21. Temos • Pasikliautinas procesas • Pasikliautinas programavimas • Klaidų toleravimas (klaidų toleravimo veiksmai, metodai, klaidos aptikimas, žalos įvertinimo metodai, klaidos toleravimas, saugios tvarkymų procedūros) • Klaidų toleravimo architektūros

22. Klaidų toleravimas • Kritinėse situacijose PĮ sistemos turėtų toleruoti klaidas. Klaidų toleravimas yra būtinas ten, kur yra aukšti reikalavimai parengtumui (availability) arba kur dėl neteisingo sistemos veikimo patiriami labai dideli nuostoliai • Klaidų toleravimas reiškia, kad sistema gali tęsti operaciją nežiūrint blogo PĮ veikimo • Net jei atrodo, kad sistema yra be klaidų, vis tiek jos turėtų būti toleruojami, nes gali būti specifikacijų klaidų arba atestavimas gali būti neteisingas

23. Klaidų toleravimo veiksmai • Klaidų aptikimas • Sistema turi aptikti, kad defektas (neteisinga sistemos būsena) pasirodė • Žalos įvertinimas • Sistemos dalys, kurias paveikė defektas, turėtų būti surastos • Klaidos atstatymas (recovery) • Sistema turi atstatyti savo būseną į žinomą saugią būseną • Klaidos taisymas (repair) • Sistema gali būti modifikuota taip, kad būtų užkirstas kelias defektų pasikartojimui. Kadangi daugelis PĮ defektų yra trumpalaikiai (transitory), tai dažnai yra nereikalinga

24. Klaidų toleravimo metodai • Gynybinis programavimas (defensive programming) • Programuotojai įtaria, kad gali būti defektų sistemos kode, todėl įdeda į jį perteklingą kodą (redundant code), tikrinantį sistemos būseną po modifikacijų, tam, kad garantuotų modifikacijos teisingumą • Defektus toleruojančios architektūros • PĮ ir Aparatūrinės Įrangos (AĮ) sistemų architektūros, kurios palaiko AĮ ir PĮ perteklingumą bei defektų toleravimo kontrolerį, aptinkantį problemas ir palaikantį defektų atstatymą • Tai yra labiau vienas kitą papildantys negu prieštaraujantys metodai

25. Klaidų aptikimas • Pirmas žingsnis klaidų toleravime yra nustatyti, kad klaida (klaidinga sistemos būsena) įvyko ar įvyks. • Klaidos aptikimui reikia apibrėžti apribojimus, kurie turi būti išlaikyti visoms legalioms būsenoms ir patikrinti ar visos būsenos išpildo šiuos apribojimus.

26. Pažeidimų nustatymas • Analizuoti sistemos būseną, kad spręsti apie pažeidimus sąlygotus sistemos sutrikimo. • Įvertinimas turi nustatyti, kokia būsenų dalis buvo paveikta sutrikimo. • Bendru atveju tikrinamos visos būsenos, kad nustatyti ar jų reikšmės yra užduotam intervale.

27. Pažeidimų nustatymo metodai • Kontrolinės sumos naudojamos pažeidimų nustatymui perduodant duomenis. • Perteklinės nuorodos gali būti naudojamos duomenų struktūros vientisumo tikrinimui. • Užsiciklinimą tikrina “Watch dog timers”. Jeigu per užduotą laiką negaunamas atsakymas, konstatuojamas pažeidimas.

28. Klaidos koregavimas ir taisymas • Tiesioginis koregavimas • Taisomas pažeistas sistemos būvis. • Atstatomasis koregavimas • Atstatomas sistemos būvis į žinomą saugų būvį. • Tiesioginiam koregavimui paprastai reikalingos specialios tos srities žinios, kad paskaičiuoti galimus būvio koregavimus. • Atstatomasis koregavimas yra paprastesnis. Išsaugomi saugūs būviai ir jais pakeičiami pažeisti sistemos būviai.

29. Temos • Pasikliautinas procesas • Pasikliautinas programavimas • Klaidų toleravimas • Klaidų toleravimo architektūros (aparatūros tolerantiškumas klaidoms, programinės įrangos tolerantiškumas klaidoms, programavimo įvairovė, N-versijų programavimas, įvairovės problemos, koregavimo blokai, specifikacijos priklausomybė, pertekliškumas)

30. Klaidoms tolerantiška architektūra • Gynybinis programavimas negali susidoroti su defektais, kurie susidaro dėl sąveikų tarp AĮ ir PĮ • Neteisingai suprasti reikalavimai gali reikšti, jog tikrinimai (checks) ir su šiais susijęs kodas yra neteisingi • Sistemoms, kurioms keliami aukšti tinkamumo reikalavimai, gali būti reikalinga specifinė architektūra, suprojektuota tam, kad palaikytų klaidų toleravimą • Ši architektūra turėtų toleruoti tiek aparatūrinės, tiek ir programinės įrangos sutrikimus

31. Aparatūrinės įrangos tolerantiškumas klaidoms • Priklauso nuo trigubo modulinio perteklingumo (triple-modular redundancy - TMR) • Yra 3 identiškos komponentų kopijos, kurios priima tokius pačius duomenis ir kurių rezultatai yra palyginami • Jeigu vienas iš trijų rezultatų yra kitoks, jis yra ignoruojamas, ir daroma išvada, kad įvyko modulio trikis • Paremtas labiau atskirų komponentų sutrikimais nei projektavimo defektais, ir žema tikimybe, kad komponentai pradės veikti neteisingai vienu metu

32. Aparatūrinės įrangos patikimumas naudojant TMR A 1 Išėjimų palyginimas A 2 komparatorius A 3 Klaidų

33. Išėjimo rezultatų parinkimas • Išėjimai palyginami aparatūriškai. • Teisingi išėjimo rezultatai parenkami daugumos balsavimu. • Klaidingas mazgas gali būti taisomas arba išjungiamas.

34. Klaidas toleruojančios programinės įrangos architektūros • TMR sėkmė, užtikrinant klaidų toleravimą, pagrįsta dviem pagrindinėm prielaidom: • Techninės įrangos komponentai neturi bendrų projektavimo defektų • Komponentai sutrinka atsitiktinai ir yra maža tikimybė, kad komponentų klaidos susidarys vienu metu • Nė viena iš šių prielaidų netinka programinei įrangai: • Nėra taip paprasta atkartoti tą patį komponentą, nes jo kopijos turės bendrų projektavimo klaidų • Todėl faktiškai yra neišvengiama, kad komponentų trikiai susidarys vienu metu • Todėl programinės įrangos sistemos turėtų būti skirtingos

35. Projektavimo įvairovė • Skirtingos sistemos versijos yra suprojektuotos ir realizuotos skirtingais būdais. Dėl to jos turėtų turėti skirtingų tipų klaidas • Skirtingi projektavimo metodai (pvz., objektiškai orientuotas ir funkcinės paskirties (function oriented)) • Realizavimas skirtingomis programavimo kalbomis • Skirtingų įrankių ir vystymo aplinkų naudojimas • Realizacijai naudojami skirtingi algoritmai

36. TMR analogai programinei įrangai • N – versijų (N-version) programavimas • Ta pati specifikacija realizuojama skirtingose versijose skirtingų darbo grupių. Visos versijos skaičiuoja vienu metu ir dauguma išėjimų rezultatų yra išrenkami naudojant balsavimo sistemą • Paprastai tai yra labiausiai naudojamas metodas, pavyzdžiui, Airbus 320

37. Versija 1 Išėjimų komparatorius Versija 2 Sutartas rezultatas Versija 3 N - versijų N-versijų programavimas

38. Išvesčių palyginimas • AĮ sistemose, išvesčių komparatorius yra paprasta programėlė, kuris naudoja balsavimo mechanizmą atrenkant išvesties rezultatus • Realaus laiko sistemose gali būti reikalaujama, kad skirtingų versijų rezultatai būtų pateikti tam tikruose laiko rėmuose

39. N – versijų programavimas • Skirtingos sistemos versijos yra suprojektuotos ir realizuotos skirtingų darbo grupių. Manoma, kad egzistuoja maža tikimybė, jog jos padarys tokias pačias klaidas. Naudojami algoritmai turėtų būti skirtingi, bet gali būti ir kitaip • Yra keletas bandymais paremtų įrodymų, kad paprastai darbo grupės tokiu pačiu būdu klaidingai interpretuoja specifikacijas ir pasirenka tuos pačius algoritmus savo sistemoms

40. Projektavimo įvairovės problemos • Darbo grupės nėra kultūriškai skirtingos, taigi jos linkusios spręsti problemas tuo pačiu būdu • Būdingos klaidos • Skirtingos komandos daro tas pačias klaidas. Kai kurios realizacijos dalys yra sudėtingesnės nei kitos, taigi visos komandos linkusios daryti klaidas tose pačiose vietose • Specifikacijos klaidos • Jei jau specifikacijoje yra klaida, tai atsispindi visose realizacijose • Tai gali būti išspręsta iki tam tikro laipsnio, naudojant įvairias specifikacijų reprezentacijas

41. Specifikacijos priklausomybė • Abu programinės įrangos pertekliškumo būdai jautrūs specifikacijos klaidoms. Jei specifikacija neteisinga, sistema gali žlugti • Tokia pati problema egzistuoja ir su technine įranga, bet PĮ specifikacijos paprastai yra sudėtingesnės ir jas sunkiau atestuoti • Kai kuriais atvejais tai buvo išspręsta, sukuriant atskiras PĮ specifikacijas pagal tą pačią vartotojo specifikaciją

42. Ar reikalingas programinės įrangos pertekliškumas? • Priešingai nei AĮ, programinės įrangos defektai nėra neišvengiamas realaus pasaulio padarinys • Todėl kai kurie žmonės mano, kad aukštesnis patikimumo ir tinkamumo lygis gali būti pasiektas stengiantis mažinti programinės įrangos sudėtingumą • Perteklinė programinė įranga yra žymiai sudėtingesnė, taigi dėl klaidas toleruojančių kontrolerių atsiranda papildomos klaidos, kurios veikia sistemos patikimumą

43. Esminiai aspektai • Sistemos pasikliautinumas gali būti pasiektas išvengiant klaidų ir jas toleruojant • Pertekliškumo ir įvairovės naudojimas yra esminiai kuriant pasikliautinas sistemas. • Kai kurios programavimo kalbų konstrukcijos, tokios kaip goto, rekursija ir rodyklės, yra neatsparios loginėms klaidoms • Griežti duomenų tipai leidžia aptikti klaidas kompiliavimo metu

44. Esminiai aspektai • Klaidų toleravimo architektūra priklauso nuo trigubo modulinio perteklingumo (triple-modular redundancy - TMR) • N-versijų programavimas yra naudojamas projektuojant klaidų toleravimą programinės įrangos architektūroje • Projektavimo įvairumas - būtina sąlyga, naudojant programinės įrangos pertekliškumą

45. Esminiai aspektai • Kritinių sistemų kūrimas Esminiai aspektai ( Pasikliautinumas, pertekliškumas, kalbos konstrukcijos, duomenų tipai, klaidų toleravimo architektūra, N- versijų programavimas, projektavimo įvairumas)

46. Klausimas 9.1 • Kaip pasiekiamas sistemų pasikliautinumas?

47. Klausimas 9.2 • Kokia klaidų toleravimo architektūra?

48. Klausimas 9.3 • Kodėl reikalinga programavimo įvairovė?

49. Klausimas 9.4 • Kas tai yra gynybinis programavimas?

50. Klausimas 9.5 • Požiūris į pertekliškumo ir pasikliautinumo santykį?