Formalni postupci u oblikovanju računalnih sustava 2008 god

Formalni postupci u oblikovanju računalnih sustava 2008. god. Nositelj: Prof. dr. sc. Nikola Bogunović ( D-309 ) Nikola. Bogunovic@fer. hr Asistenti: Igor. Grudenic@fer. hr Alan. Jovic@fer. hr Ivan. Zuzak@fer. hr - D 342 - D 340 - D 338 1

Detaljna satnica i nastavni materijali : http: //www. zemris. fer. hr/ ----> FPORS http: //www. fer. hr/predmet/fpuors Predavanja: Petak: 09: 15 -- 11: 00, B 4 Auditorne i dopuna predavanja: Ponedjeljak: 08: 15 -- 10: 00, D 1 (Osim prvih auditornih: Ponedjeljak, 03. 2008. , 14: 15 -16: 00, D 1 ) Na auditornima rješavanje ispitnih zadataka ! Labs: Ponedjeljak: 14 -18, A-102, A-101, kolokviranje !! 2

Laboratorijske vježbe (uvjet za potpis) 6 vježbi uz kolokviranje, izrada slobodno ili u labu, pomoć skripta i auditorne. Kolokviji iz vježbi (6): prema rasporedu (ponedjeljkom 14: 00 - 18: 00) 20 min 3 + 3 regularna termina + 2 za nadoknadu Ukupan broj bodova svih vježbi (6 x max 5 = max 30) Normalizira se na max 6. 0 Uvjet za potpis: 2. 0 Ispitivanje sustava: 10. 03. 2008. , 14: 00 – 16: 30 po rasporedu dolazak = 0. 6 (1/10 od max 6 boda) – nije obvezno Poslije ispitivanja (od 16: 30 do 18: 00) lab je otvoren za neobveznu izradu 1. vježbe. Prvi kolokvij (od 6) iz labosa: 17. 03. 2008. , PO RASPOREDU 3

KONTROLNE ZADAĆE 1. Kontrolna zadaća: Petak, 11. 04. 2008. , 10: 00 – 12: 00, više dvorana po rasporedu 2. Kontrolna zadaća Petak, 30. 05. 2008. , 10: 00 – 12: 00 više dvorana po rasporedu Obavijesti na: http: //www. zemris. fer. hr/ ----> http: //www. fer. hr/predmet/fpuors FPORS 4

Ocjena: Normalizacija i maksimalni bodovi: Kontr. zadaća 1 : Kontr. zadaća 2 : 10 b (min 25% od najbolje) K 1 i K 2 uključuju gradivo iz predavanja i labosa. K 2 nema sadržaja iz K 1. Lab. vježbe : Ukupno : 6 b (min 2, uvjet za potpis) _______ 26. 0 boda U ocjenu na reg. roku ulazi ocjena iz labosa (20 + 6 b). Lagane zadaće: od 13 do 26 boda Teže zadaće: od 11 do 26 boda Za ocjene preko kontrolnih zadaća moguća razdioba: 15% (5), 35% (4), 35% (3), 15% (2) (Bologna !) 5

Nastavne cjeline u predavanjima: www. zemris. fer. hr/ ----> FPORS/Pred. 1. Uvod 2. Labs http: //www. zemris. fer. hr/ ----> FPORS/lab. 3. Logika (predikatna i vremenska CTL) 4. Verifikacija provjerom modela (MC) 5. Logičke funkcije i predstavljanje BDD-ovima 6. Verifikacija uporabom BDD-ova 7. Modeli u sklopovsko-programskom suoblikovanju 8. Petrijeve mreže 9. Stilovi arhitekture programskih sustava 10. UML 6

Događaj 1 (1985 -1987) Therac-25: sustav za terapiju radioaktivnim zračenjem (elektroni ili fotoni do 25 Me. V) • 6 fatalnih pogrešaka (prekomjerne doze) • Najgori akcident u 40 godina terapije zračenjem • Program: - DEC PDP 11 asembler - konkurentni prosesi - “test and set” nije bila nedjeljiva operacija - višestruki upis u zajedničke varijable 7

Događaj 2 (1994/5) Pentium mikroprocesor Pogreška u računanju s pomičnim zarezom (“floating point”). Izostala formalna verifikacija (“corner bug”). Trošak: 500 Mil USD. 8

Software “HALL OF SHAME”: 1993: London Stock Exchange ($ 600 M, canceled) 1996: Arianespace (Ariane 5 rocket explosion, $350 M) 1999: State of Mississippi (Tax system, $185 M loss) 2001: Nike Inc. (Supply chain management, $100 M loss) 2002: Mc. Donald’s (Purchasing system canceled, $170 M) 2004: Hewlett-Packard (Management system, $160 M loss) 2004: Sainsbury food chain, UK ($527 M, canceled) 2004: Ford Motor Co. (purchasing, $400 M, canceled) 2004: Mars Spirit, NASA: "a serious software anomaly“ 2005: UK Tax (soft errors resulted in $3. 5 G (billion) overpay). . . 9

Tradicijski postupak oblikovanja sustava (1): aktivnost Analiza zahtjeva rezultat Specifikacija sustava Odjeljivanje sklopovlja i programskih dijelova Opis sklopovlja Opis programa 10

Tradicijski postupak oblikovanja sustava (2): Opis sklopovlja Sinteza i konfiguracija sklopovlja Konf. moduli Opis programa Sinteza i konfiguracija programa Sinteza sučelja Sklopovske komponente HW/SW sučelje Progr. moduli HE/SW integracija Evaluacija sustava Verifikacija sustava 11

Nedostaci tradicijskog postupka oblikovanja sustava Analiza i oblikovanje: • Zahtjevi nisu formalizirani (nemoguće postići preciznost, neodređenost vodi u nekompatibilnost) • Izgradnja prototipa (neformalni prototipovi ne omogućuju dublju analizu) • Procjena performanci (neformalni modeli daju pogrešne vrijednosti) • Dijeljenje na sklopovski i programski dio nije poduprt formalnim transformacijama • Dokumentaciju teško interpretirati Ručna provjera: • Nedovoljno duboka • Ljudski um nije u mogućnosti predvidjeti sve moguće interakcije u složenim sustavima. 12

Problemi ispitivanja (testiranja) sustava • Cijena testiranja čini najveći dio cijene produkta. • Ljudski um nije u mogućnosti predvidjeti sve moguće interakcije u složenim sustavima. • Pokrivenost skupa testiranih stanja se smanjuje. • Podupire se podupire mentalitet “kolektivne krivnje”. • “Corner cases” se sve teže identificiraju. • Vrijeme stavljanja proizvoda na tržište (“time to market”) diktira kratko testiranje. Posljedica: NEISPRAVNI SUSTAVI 13

Posebice: tradicijsko oblikovanje programskih produkata • Formulacija zahtjeva (“requirements”, što bi sustav trebao raditi). • Specifikacija i analiza. • Oblikovanje (kako će sustav ispuniti ciljeve). • Kodiranje (stvarno programiranje). • Testiranje modula. • Integracija i testiranje sustava. Ispravnost se provjerava simulacijama i testiranjem koje: mogu samo dokazati postojanje pogreške (“bug”) ali nikada njeno nepostojanje (Dijkstra) !! Što učiniti ? 14

15

16

17

18

19

20

Engineering Models w Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint Modeled system Functional Model w We don’t see everything at once w We use a representation (notation) that is easily understood for the purpose on hand 21 IBM Software Group |

22 IBM Software Group |

23

24

25

Moderan postupak oblikovanja sustava (1): Analiza zahtjeva aktivnost Specifikacija sustava Modeliranje Poboljšani model Model sustava Funkcijska obilježja NE rezultat Poboljšanje Validacija Verifikacija i simulacija Kritična obilježja Validirani model DA Verificirani i simulirani model sustava 26

Moderan postupak oblikovanja sustava (2): Verificirani i simulirani model sustava Utvrđivanje tehnologije “component-based design - IPs” Sklopovlje Sučelja Evaluacija sustava Programske komponente 27

Temelji formalne verifikacije (FV) Dva objekta: S - specifikacija (što sustav treba raditi) - formal. spec. I - implementacija (kako to sustav radi) - formal. model Odredi da li: I odgovara S. “Odgovara”: ekvivalencija, simulacijske relacije, logička zadovoljivost, logička implikacija, implementacijske relacije, … 28

Primjeri: Ulazno/izlazni programi: S: y = x 2 I: y = 1 + 3 + … + (2 x - 1) Reaktivni programi: trajna interakcija s okolinom (operacijski sustavi, upravljanje avio letovima, upravljanje nuklearnim reaktorom, …) S, I: formalizacija njihovog ponašanja tijekom vremena 29

Formalna verifikacija postupak provjere da formalni model izvedenog sustava (/), odgovara formalnoj specifikaciji (S) sa matematičkom izvjesnošću I Da / Ne Sustav za verifikaciju S 30

Pažnja: Često se oglašava da FV daje apsolutnu sigurnost u ispravnost sustava (programa/sklopovlja). iako FV garantira izvan svake sumnje samo ispravnu relaciju između formalnih (matematičkih) objekata I i S. FV ne osigurava ispravnu relaciju između stvarne implementacije i specifikacije. Temeljno: radi se s modelima (apstrakcijama) stvarne implementacije 31

Razlozi neispravnosti postupka i rezultata FV 1. Razlika između matematičkih objekata i realnosti model I nije obuhvatio bitna obilježja realne implementacije (npr. ograničena duljina riječi, precizna informacija o vremenskim odnosima i sl. ). Model S pretpostavlja suviše jaka ograničenja okoliša. 2. Neadekvatna specifikacija S ne opisuje intencije korisnika. S je nekompletan ili neispravan (opisuje krivo ponašanje). 32

Kako specificirati “što želimo” (formalan opis, S): Logika predikata prvoga reda: X [c (X b)] Vremenska logika: “Signal REQ mora biti istinit i ostati istinit sve dok signal GRANT ne postane istinit” Modeli implementacije ( I ): Regularni jezici Automati s konačnim brojem stanja ( Opisi su ekvivalentni) 33

Vremenska logika Specifikacija S (ponašanje u budućnosti): “Nikada se ne smije dogoditi da su vrata otvorena dok se lift kreće”, t. j ( otvorena_vrata lift_se_kreće ) mora uvijek biti neistinito. Primjer specifikacije: AG ( otvorena_vrata lift_se_krece) Emerson - Clarke notacija (gornji primjer) Pnueli - Manna notacija: 34

Okosnice za FV Algoritamska verifikacija –Provjera modela Istraživačka tehnika za strojeve s konačnim brojem stanja. Pobrojavanje (enumeriranje i simboličke varijante). Postupci zasnovana na dokazivanju teorema ( ATP ) Primjenjivi na sustave s beskonačnim brojem stanja. Zahtijevaju interakciju korisnika (ekspertno znanje). 35

Provjera modela (engl. Model Checking) Treba dokazati da vremenski specificirano obilježje vrijedi tijekom svih ponašanja sustava (engl. computations). Dokaz da obilježje p vrijedi tijekom svih ponašanja sustava: Konstruiraj sva stanja dosezljiva iz početnih. Provjeri da svako stanje zadovoljava obilježje p. Temeljni problem: izračun svih dosezljivih stanja (“reachability analysis”) Simbolički postupci: predstavljanje skupova, relacija (funkcija) s logičkim funkcijama, a ove sa BDD. Danas postignuto: sustavi sa ~ 10500 stanja 36

2007 Turing Award Winners Announced for their groundbreaking work on Model Checking Edmund M. Clarke, E. Allen Emerson, and Joseph Sifakis are the recipients of the 2007 A. M. Turing Award for their work on an automated method for finding design errors in computer hardware and software. The method, called Model Checking, is the most widely used technique for detecting and diagnosing errors in complex hardware and software design. It has helped to improve the reliability of complex computer chips, systems and networks. 37

FV u praksi: Poluvodička industrija (ASICS i drugi sklopovi visoke integracije): formiranje istraživačkih i razvojnih odjela, uvođenje FV Komunikacijski protokoli često su formalno verificirani Sigurnosno-kritični sustavi uskoro će se zahtijevati FV Programsko inženjerstvo slabo prihvaćanje FV tehnika ? ? 38

Zašto postupci FV nisu široko prihvaćeni Ne uči se na sveučilištima. ; -) Usredotočenost na ulazno/izlazne scenarije. Tradicija ( nedovoljno matematike u računarstvu ). “Formalisti” su također krivi jer: Mnogi nemaju iskustva na stvarnim sustavima. Reklamiraju i ono što se sa FV ne može postići. Često se ekstrapolira (“silver bullets” traže vrijeme). 39

Cross. Talk, The Journal of Defense Software Engineering January, 2008 Computer Science Education: Where Are the Software Engineers of Tomorrow? Computer science professors at New York University, say that today's computer science graduates are not equipped with the skills they need to work well in the current software industry, leading to the conclusion that "we are training easily replaceable professionals. " They recommend an approach to CS education characterized by the earlier introduction of formal methods such as model checking. 40

Spas u formalnim metodama (FM) (US Computer Science and Technology Board) FM trebaju biti ključna inženjerska vještina u računarstvu koja povećava kakvoću produkta I istodobno smanjuje vrijeme stavljanja produkta na tržište (“time to market”), te se mora uključiti u izobrazbu CS i EE. Treba razlikovati matematičke osnovice (teorija domena, teoriju čvrste točke, propozicijska i predikatna logika, teorija automata, teorija grafova i sl. ) od formalnih postupaka ( Z metoda, provjera modela, funkcijsko programiranje i sl. ). 41

FM džungla ACL 2, ACP, ASR, Action Semantics, Argos, ASM, ADLT, BDDs, B, Boyer-Moore, Caesar/Aldebaran, CCS, Circal, COLD, Coq, COSPAN, CSP, FDR 2, CWB, Dis. Co, DC, Estelle, EVES, GIL, HOL, Hy. Tech, IMPS, I/O Automata, ITL, Isabelle, JAPE, KIV, Kronos, LAMBDA, LARCH, Lean. Ta. P, LEGO, LOTOS, Lustre, MALPAS, Meije, Mizar, CRL, Murphi, NP-tools, Nqthm, Nuprl, Obj, Otter, Petri Nets, PI-calculus, Pobl, Proof. Power, PVS, RAISE, Rapide, Refinement Calculus, SDL, SGM, Signal, SMV, SPARK, SPIN, Step, TAM 97, Temporal-Rover, TLA, TPS, TRIO, TTM/RTTL, Unity, Uppaal, Veri. Soft, VDM, VIS, Z, … 42

Gdje smo u evoluciji formalnih postupaka oblikovanja Semantika ima dobru teoretsku osnovicu ali slabu primjenu. Postupci oblikovanja sustava imaju dobru primjenu ali slabu teoretsku osnovicu. Budući ključni rad: razumjeti, razvijati i uspoređivati različite računalne modele (“models of computation”) 43