Kritinių sistemų kūrimas

©Ian Sommerville 2015 Dependable systems specification Slide 1

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ą.

Įžanga• Kritinių sistemų kūrimas Įžanga (Tikslai, temos,

pasikliautinumas, įvairovė ir pertekliškumas, programos be klaidų, jų kūrimas, klaidų ištaisymo kaštai)

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

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

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ų

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ų.

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

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

Klaidų ištaisymo kaštai

Mažai

Neišaiškintų klaidų kiekis

Daug Labaimažai

Vienos klaidos

pašalinimo

kaštai

Temos• Pasikliautinas procesas (kūrimo procesas,

charakteristikos, atestavimo veiklos) • Pasikliautinas programavimas• Klaidų toleravimas• Klaidų toleravimo architektūros

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

Pasikliautino proceso charakteristikos

Dokumentuojamas The process should have a defined process model that sets out the activities in the process and the documentation that is to be produced during these activities.

Standartizuotas A comprehensive set of software development standards that define how the software is to be produced and documented should be available.

Audituotas The process should be understandable by people apart from process participants who can check that process standards are being followed and make suggestions for process improvement.

Su išsamiu testavimu The process should include redundant and diverse verification and validation activities.

Atsparus klaidoms The process should be able to recover from failures of individual process activities.

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

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ą.

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.

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

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ų

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

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

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

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

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

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

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.

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.

• 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.

Pažeidimų nustatymo metodai

• 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.

Klaidos koregavimas ir taisymas

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)

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

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

Aparatūrinės įrangos patikimumas naudojant TMR

komparatorius

Klaidų

Išėjimųpalyginimas

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.

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

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 kalbomisSkirtingų įrankių ir vystymo aplinkų naudojimasRealizacijai naudojami skirtingi algoritmai

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

N-versijų programavimas

Versija 1

Versija 3

Išėjimų komparatorius

N - versijų

Sutartasrezultatas

Versija 2

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

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

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

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ą

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ą

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

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ą

Esminiai aspektai• Kritinių sistemų kūrimas Esminiai aspektai

( Pasikliautinumas, pertekliškumas, kalbos konstrukcijos, duomenų tipai, klaidų toleravimo architektūra, N- versijų programavimas, projektavimo įvairumas)

Klausimas 9.1• Kaip pasiekiamas sistemų pasikliautinumas?

Klausimas 9.2• Kokia klaidų toleravimo architektūra?

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

Klausimas 9.4• Kas tai yra gynybinis programavimas?

Klausimas 9.5• Požiūris į pertekliškumo ir pasikliautinumo

santykį?

Kritinių sistemų kūrimas

Documents

TEKSTO KŪRIMAS (remtasi Z.Nauckūnaitės medžiaga)

ryšiai su visuomene, nuoseklus įvaizdžio kūrimas

Geoinformacinių sistemų pagrindai

TIESINIŲ LYGČIŲ SISTEMŲ SPRENDIMO

Samprotavimo rašinio įžangos kūrimas

Programų sistemų testavimas

Hidraulinis šildymo sistemų balansavimas

Interneto svetain ės kūrimas

Atvirų švietimo išteklių kūrimas

TEKSTO KŪRIMAS

Kritinių sistemų kūrimas

„Auklėjimas – tai žmogaus ateities kūrimas“

Grupės kūrimas - vyturys.kaunas.lm.lt

Valdymo sistemų klaidų diagnozė

Valstybės informacinių sistemų reglamentavimas

TEKSTŲ KŪRIMAS IR RAŠYMAS TEKSTŲ PAVYZDŽIAI

Įvaizdžio kūrimas

Prezentacijų kūrimas su LaTeX Beamer

Programų sistemų inžinerija

Facebook puslapio kūrimas